Fan out one events module per subscription behind an organization flag or environment opt-in - #8426
Draft
rezaansyed wants to merge 1 commit into
Draft
Conversation
…g or environment opt-in Assisted-By: devx/aa56a38c-289a-416e-8a9a-0de281e4e3e7
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?
Stacked on #8425.
Shopify Core is migrating
eventsapp modules from one list-shaped module (subscription: [...], uid"events") to one single-subscription module per subscription (subscription: {...}, uid = subscription handle). The Core contract, uid derivation, and validation already support both shapes; this PR makes the CLI deploy the new shape.WHAT is this pull request doing?
loader.ts): when enabled, each[[events.subscription]]entry in the TOML becomes its owneventsmodule instance with{events: {api_version, subscription: <object>}}— the single shape Core recognizes. The fan-out runs insidecreateConfigExtensionInstancesso theeventskey is still claimed (no "Unsupported section(s)" false positive). The tuple shape changed from[instance, keys]to[instances[], keys].extension-instance.ts): for a single-shape events config,buildHandle/buildUIDFromStrategyreturn the subscription handle — shape-driven and strategy-agnostic, mirroring Core's uid derivation (uid = subscription handle). Duplicate subscription handles are rejected by the loader's existing global duplicate-handle check.f_single_subscription_events_modules_cli, fetched inappFromIdentifiersvia the existingorganizationExpFlagsBusiness Platform query and surfaced through the previously-emptyFlagenum /remoteFlagspipe (Flag.SingleSubscriptionEventsModules), best-effort with a catch-all so a failed lookup never breaks a command; orSHOPIFY_CLI_EVENTS_SUBSCRIPTION_FANOUTenv var as a local opt-in/escape hatch.Core's per-app Verdict flag remains the authoritative server-side gate: a fanned-out deploy for an app that isn't allowed the single shape fails loudly at Core validation.
How to test your changes?
pnpm vitest run src/cli/models/app/loader.test.ts src/cli/utilities/developer-platform-client/app-management-client.test.ts src/cli/models/extensions/extension-instance.test.ts(new tests: fan-out shapes/handles/uids via env var, fan-out via remote flag, disabled path unchanged, duplicate-handle rejection, exp-flag enabled/disabled/failure inappFromIdentifiers).SHOPIFY_CLI_EVENTS_SUBSCRIPTION_FANOUT=1, add two[[events.subscription]]entries with handles, runapp deployagainst an app allowlisted in Core — the version should contain twoeventsmodules whose uids are the subscription handles.Post-release steps
f_single_subscription_events_modules_clibefore ramping (until then the env var is the only way to enable fan-out).Measuring impact
next_gen_events.list_shape_module_validatedmetric declineChecklist