fix(relay): tunnel limit counts abandoned reprovisions and frees failed revokes#26320

Problem

Two edge states in the managed tunnel quota count (ManagedTunnelLimits.ts):

1. Quota bypass. The live-tunnel branch skipped any allocation whose link was revoked or publish-only, with no time bound. If a revoked environment was reprovisioned (recordTunnel succeeded) but the Worker died, or links.upsert failed, before the link was rewritten, the environment held a live Cloudflare tunnel and counted as zero once the 15-minute pending window passed. A user could repeat that for B, C, and so on.
2. Wrongful refusal. unlinkEnvironmentRecord commits the revoke (link updatedAt T1), then claimDeprovision bumped the allocation's updatedAt to T2 > T1. When the Cloudflare delete failed, the pending branch counted the row again because the revoke now looked older than the allocation. Each retry pushed T2 forward, so a user at the limit stayed refused for as long as cleanup kept failing.

Fix

Both fixes rely on one rule: allocation updatedAt changes only when the allocation is provisioned (reserve, recordTunnel, recordDns, markReady, enableRecovery) or released (claimRelease with markReleased, which also sets tunnelReleasedAt). Teardown claims (claimDeprovision and unmarked claimRelease) now bump only generation, and generation was already the guard those claims check. Nothing else reads allocation updatedAt.

With that rule, both branches use the same bounded check, withdrawnLink(allocation.updatedAt):

• A link withdrawn at or after the last provisioning write means cleanup is owed, so the row is excluded. That covers a revoke whose deprovision fails, however many times it is retried.
• A link withdrawn before the last provisioning write means a relink started and never finished, so the row counts.
• Publish-only links are still excluded: EnvironmentLinker deprovisions before it writes the publish-only link, so the link is always newer.

Rows written before this deploy

Today's code leaves rows where a failed deprovision bumped updated_at past the revoke. Under the new live branch, those rows would read as "relink never finished" and hold a slot forever. Nothing would clear them, because retries no longer move updated_at. To size it, an operator can run this read-only query against production:

Migration 20261028062605_backfill_withdrawn_tunnel_allocations makes this safe whatever the count is. It sets those rows' updated_at to their link's updated_at, which is the value the new write rule would have left.

• Live-table safety: one UPDATE that matches only withdrawn links with an unreleased tunnel, which should be a handful of rows. It takes row locks only on those rows, inside the runner's migration transaction. It does not touch generation, so in-flight claims and provisioning are unaffected; if the migration locks a row first, a concurrent recordTunnel waits, then writes a newer updated_at and correctly counts. If recordTunnel commits first, the row still matches, so the migration moves updated_at back and briefly treats that in-flight reprovision as abandoned; its next recordDns or markReady write bumps it again.
• Idempotent: after the update, l.updated_at = a.updated_at, so a second run matches nothing.
• Verified: with Alchemy's real runner (runMigrations plus makePgMigrationExecutor) over PGlite. All 14 migrations apply, a rerun is a no-op, and the UPDATE touches 1 row on its first run and 0 on its second.
• No predicate-only alternative: a pre-deploy failed deprovision and a pre-deploy abandoned reprovision leave the same columns behind (live tunnel, link withdrawn before updated_at), so no predicate can tell them apart without a marker.
• Accepted cost (pre-deploy rows only): an abandoned reprovision from before the deploy (finding 1's case) is also freed once by the backfill. That matches main's behaviour for those rows, which already stopped counting after 15 minutes. Abandoned reprovisions after the deploy count.
• Rollout window: a revoke retried by an old Worker between the migration and the Worker rollout could bump updated_at once more and recreate one such row. So can the reaper's unmarked claimRelease on a publish-only row (it sweeps every 5 minutes). The query above finds such rows, and re-running the same UPDATE clears them. A possible follow-up would let the new Worker repair these on its own (claimDeprovision and unmarked claimRelease setting updated_at to the earlier of itself and the withdrawn link's), so no operator step is needed.

Deleted tunnel, failed allocation removal

deprovision deletes the tunnel and then removes the allocation inside one transaction. If the removal or the commit fails, the rollback keeps the deleted tunnel's id, and a later stalled relink would make the limit count a tunnel that no longer exists. After a confirmed delete, a failed deprovision now marks the row released (claimRelease with markReleased, guarded by tunnel id and claimed generation), so it counts only for the pending window. Clearing tunnelId on reserve would break reuseReadyTunnel and stop counting tunnels that survived a failed delete, so this PR doesn't do that.

Known edge, unchanged

The recovery-versus-revoke race in Api.ts (~680-740) is left as it is. A recovery write that lands after a revoke moves updated_at past the link, so the row counts until it is deprovisioned. The review judged that an acceptable trade-off for closing the quota bypass.

I skipped SET LOCAL lock_timeout. It needs a separate statement, which adds a round trip to every link, and the fake transaction in the test models every execute as the advisory lock.

Tests

• ManagedTunnelLimits.test.ts applies the real migration files to PGlite and evaluates the exported count condition for each state: pending, abandoned reservation, live, released, re-reserved after release, revoked, revoked while pending, publish-only, reprovisioned after a revoke without a link rewrite, reserved before a link rewrite, a tie (link updatedAt equal to allocation updatedAt, so withdrawn), the environment's own row, and another user's row.
  • Pre-deploy rows (a failed revoke deprovision, a failed publish-only deprovision, and a live control) are inserted before the backfill migration runs. Without the migration, both failed rows count.
  • Changing gte to gt in withdrawnLink fails the tie case.
• ManagedEndpointProvider.test.ts checks that a failed allocation removal after a successful tunnel delete marks the row released. The PGlite table covers that row after a stalled relink.
• ManagedEndpointAllocations.test.ts checks that teardown claims leave updatedAt alone and that a marked release sets updatedAt equal to tunnelReleasedAt. It still uses a fake set(): running claimDeprovision against PGlite would need an Effect drizzle client over PGlite, which is more harness than this PR should add.
• @electric-sql/pglite@0.3.15 is now a relay devDependency. It was already in the lockfile and installed as drizzle-orm's optional peer, so nothing new is downloaded.

Model and harness: Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code