Repository navigation
Conversation
…s it `store delete -s <store>` failed with "Could not determine which organization owns <store>" for any store the service account hadn't created itself, and `store info` said the store couldn't be found, even though the same commands worked with `--organization-id` and the token belongs to exactly one organization. Both commands locate a store's organization through Business Platform's destinations search, which only lists stores the account itself can open. A service account can open only the stores it created; a person can belong to an organization without a seat on every store. The Organizations API, which the commands then use, lists every store the account may manage, so the miss was in the lookup, not the access. When the destinations lookup comes up empty and the account belongs to one organization, that organization is used, the way `store list` already auto-selects it. `store delete` goes straight to it instead of failing non-interactively or prompting. `store info` looks the store up through the Organizations API there, and still reports the store as not found when that misses too. Accounts in several organizations keep the prompt and the `--organization-id` requirement. Co-authored-by: Eddie Gao <eddie.gao@shopify.com>
lizkenyon
reviewed
Oct 23, 2026
| // eslint-disable-next-line no-catch-all/no-catch-all | ||
| } catch (error) { | ||
| outputDebug(`BP Organizations shop lookup in ${organization.businessName} failed: ${errorMessage(error)}`) | ||
| return undefined |
Contributor
There was a problem hiding this comment.
AI-assisted review — nonblocking
Could we preserve permission/authentication and unexpected API errors here, rather than treating them as a lookup miss? For example, an OrganizationStoreAccessError gets caught and replaced with “store not found,” hiding the guidance about granting dev-store access.
fetchOptionalOrganizationShop already returns undefined when the store genuinely isn’t found, so we can keep that fallback while letting other failures surface, consistent with the error-handling guidance.
lizkenyon
approved these changes
Oct 23, 2026
egaodd
enabled auto-merge
October 23, 2026 20:46
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WHY are these changes introduced?
Found in the service accounts bug bash (P2):
shopify store delete -s <store>failed with "Could not determine which organization owns " for any store the service account hadn't created itself, andstore infosaid the store couldn't be found, even though both commands work with--organization-idand the token belongs to exactly one organization.WHAT is this pull request doing?
Both commands locate a store's organization through Business Platform's destinations search, which only lists stores the account itself can open. A service account can open only the stores it created; a person can belong to an organization without a seat on every store. The Organizations API, which the commands use next, lists every store the account may manage, so the miss was in the lookup, not in the access.
When the destinations lookup comes up empty and the account belongs to one organization, that organization is used, the way
store listalready auto-selects it:store deletegoes straight to it instead of failing non-interactively or prompting. The organizations are listed with the same token the lookup used, withnoPromptin non-interactive runs, so a CI run with no login still gets a clean error rather than an attempt to prompt.store infolooks the store up through the Organizations API there, and still reports not-found when that misses too.--organization-idrequirement.Not changed, for a separate decision:
store create devstill requires--organization-idnon-interactively (requiredIfNonInteractive) even for a single-organization account, which contradicts the flag's own "Auto-selects if you belong to a single organization".How to test your changes?
Verified against production with two dev-store service accounts in org 299069: token A created
river-fix-store-1; with token B,shopify store info --store river-fix-store-1.myshopify.comreturned the store andshopify store delete -s river-fix-store-1.myshopify.com -fdeleted it, both without--organization-id.Unit tests in
store-lookup/organization.test.ts(single-org fallback, non-interactive token reuse, no organizations, multi-org prompt) andservices/store/info/index.test.ts(fallback hit, not-found-either, failing org lookup).tscand eslint pass on store and organizations.Measuring impact
Checklist
@shopify/cli: patch)