Fix unsupported IN operator for store_type filter in FetchStoreByDomain

[ericlee878]

Resolves: https://github.com/shop/issues-api-foundations/issues/1372

Summary

• Fix FetchStoreByDomain using the unsupported IN operator for store_type filters on accessibleShops. The backend silently ignores unrecognized operators, so the filter was never applied and all stores were returned.
• Switch to EQUALS operator via structured ShopFilterInput filters. Since the backend ANDs multiple filters, we fan out one request per store type and merge results.
• Change storeByDomain return type from OrganizationStore | undefined to OrganizationStore[] so callers receive all matches across store types.

Implmentation Details

• The IN operator is unsupported for STORE_TYPE filters in the business-platform-organizations API, and multiple filters are combined with AND logic. Since a store can't match multiple types simultaneously, we work around this by making one request per store type in parallel using EQUALS. Most call sites pass a single type (APP_DEVELOPMENT), so this is a no-op for the common path. The 4-type case (app logs, webhook trigger) makes 4 parallel requests instead of 1.

Test plan

• Existing fetchStore tests updated and passing
• Verify storeByDomain correctly filters by store type (previously all stores were returned regardless of type)
• Regenerate GraphQL types from updated .graphql query

Tophat instructions:

1. shopify app dev --path <your-app> : confirm dev store resolves normally
2. shopify app dev --path <your-app> --store <non-dev-store-domain> : should fail with "store not found", confirming the store type filter is now applied (previously all stores were returned regardless of type)

[ericlee878]

• Fix unsupported IN operator for store_type filter in FetchStoreByDomain #6963 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[binks-code-reviewer]

🤖 Code Review · #projects-dev-ai for questions
React with 👍/👎 or reply — all feedback helps improve the agent.

✅ Complete - No issues

📋 History

✅ No issues → ✅ No issues

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	79.13%	14575/18420
🟡	Branches	73.4%	7233/9854
🟡	Functions	79.25%	3713/4685
🟡	Lines	79.46%	13771/17331

Test suite run success

3816 tests passing in 1459 suites.

Report generated by 🧪jest coverage report action from 640fe55

[ryancbahan]

looks like pre-existing issue, but map is always synchronous, so this code is probably producing race conditions

[ericlee878]

Thanks for flagging! The map here is intentional. It builds an array of Promises (through businessPlatformOrganizationsRequest) that are immediately passed to Promise.all, so all requests run in parallel and we wait for all of them to resolve. No fire-and-forget happening.