refactor(cli): single-source the shadow webhooks policy on the setup input - #6221
Open
avallete wants to merge 1 commit into
Open
Conversation
…input The shadow-baseline cache key and the provisioned baseline previously expressed the Webhooks/pg_net policy independently: callers passed LegacyShadowCacheOpts.webhooks for the key while the use phase picked a provisioner that applied its own policy (legacyMigrateShadowDatabase forced "enabled", legacyMigrateNextShadowDatabase followed config, legacySetupShadowDatabase took caller options). Nothing enforced agreement, and three of five call sites had drifted before the previous commit re-aligned them by hand. Make that drift class unrepresentable: LegacyShadowDbSetupInput now carries a required webhooks policy that BOTH the cache-key resolution and every baseline provisioner read, so a published snapshot's key can never describe a different baseline than the one provisioned. The old parallel surfaces are deleted outright: LegacyShadowCacheOpts.webhooks, legacyMigrateNextShadowDatabase (one migrate function remains), the LegacySetupDatabaseOptions params on legacyOpenShadowBaselineSession/ legacySetupShadowDatabase, and legacyPrepareShadowSource's migrate dispatch. The per-engine semantics — legacy migra/pg-delta force pg_net on (Go parity), pg-delta next follows config — are named once in legacyShadowSourceWebhooksPolicy(migrationMode), which db diff/db pull use when building their shadow inputs; pgadmin, squash, the catalog exports, and pg-delta next's shadows state their fixed policies at input construction. Effective policies, cache keys, and provisioned SQL are unchanged at every call site. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
avallete
changed the title
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
1 participant
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.
Stacked on #6220 (
avallete/shadow-cache-squash-pgadmin).Summary
The shadow-baseline cache key and the provisioned baseline previously expressed the Webhooks/
pg_netpolicy independently: callers passedLegacyShadowCacheOpts.webhooksfor the key, while theusephase picked a provisioner that applied its own policy (legacyMigrateShadowDatabaseforced"enabled",legacyMigrateNextShadowDatabasefollowed config,legacySetupShadowDatabasetook caller options). Nothing enforced agreement — three of five call sites had drifted before #6220 re-aligned them by hand, and nothing stopped a sixth call site from drifting again.This makes that drift class unrepresentable.
LegacyShadowDbSetupInputnow carries a requiredwebhooks: LegacyShadowWebhooksPolicyfield that BOTH the cache-key resolution (shadow-cache.ts) and every baseline provisioner read, so a published snapshot's key can never describe a different baseline than the one actually provisioned.The old parallel surfaces are deleted outright (no shims):
LegacyShadowCacheOpts.webhookslegacyMigrateNextShadowDatabase— one migrate function remains, reading the input's policyLegacySetupDatabaseOptionsparams onlegacyOpenShadowBaselineSession/legacySetupShadowDatabaselegacyPrepareShadowSource's migrate dispatch and the pg-delta-next layer's webhooks-carryingcacheOptsThe per-engine semantics — legacy migra/pg-delta engines force
pg_neton (Go parity), pg-delta next follows config — are named exactly once, inlegacyShadowSourceWebhooksPolicy(migrationMode), whichdb diff/db pulluse when building their shadow inputs. pgAdmin,migration squash, the catalog exports, and pg-delta next's migrations/declarative shadows state their fixed policies at input construction, each with the rationale in place. The two raw-shadow sites (db pull's legacy declarative export,declarative.orchestrate.ts) pass an explicitly inert"config"— they never run a baseline or touch the cache.Effective policies, cache keys, and provisioned SQL are unchanged at every call site.