supabase / storage / 37605299303

85%

push

github

fix: treat an unrecognized tenant migration as ahead (#1483)

## What kind of change does this PR introduce?

Bug fix. Replaces #1403 with a smaller change.

## What is the current behavior?

When a tenant's `migrations_version` is a name this binary doesn't know,
`DBMigration[name]` is `undefined` and the tenant looks behind. This
happens when a newer release has already migrated the tenant, for
example during a rolling deploy or after a rollback. The old pod re-runs
migrations, writes its own older version over the newer one, and turns
off features for that tenant.

In PROGRESSIVE mode both releases share the migrations queue. An old
worker that picks up a job whose `upToMigration` it doesn't have throws,
then marks the tenant FAILED and later FAILED_STALE.

## What is the new behavior?

A version the binary doesn't know is treated as ahead.

- `getTenantConfig` reports it as the newest migration this binary knows
and sets `migrationVersionAhead`. `areMigrationsUpToDate` returns `true`
for these tenants.
- Migration state writes only apply when the stored version is null,
empty or known, so an old pod can't rewind a newer one. If the write
matches no row, the pod drops its cached config and logs it.
`resetMigration` still writes unguarded.
- The fleet listing skips tenants with an unknown version.
- Migration jobs with an unknown `upToMigration`, and reset jobs with an
unknown `untilMigration` or `markCompletedTillMigration`, fail without
touching tenant state. pg-boss retries them so a worker on the newer
release can pick them up. Before, an old worker would record a reset it
never applied.

Nothing new runs on the request path, and tenants with a null version
behave as before. This should ship before any PR that adds a migration.

## Additional context

Not covered: restored databases whose control row is ahead of the
schema, a compare-and-swap on `database_url`, and two branches using the
same migration number. During a rollout an old pod can sti... (continued)

7170 of 8973 branches covered (79.91%)

Branch coverage included in aggregate %.

29 of 29 new or added lines in 6 files covered. (100.0%)

12789 of 14525 relevant lines covered (88.05%)

781.81 hits per line