[ferhatelmas]

What kind of change does this PR introduce?

feat

What is the current behavior?

Lifecycle policy and versioning changes update the tenant db where lifecycle state is saved.
Migration 31 enrolls tenants in the central registry if feature is enabled for a tenant.
However, policy changes themselves do not wake the central tenant registry.

What is the new behavior?

After a successful policy PUT/DELETE or versioning enable, make the tenant due in the central registry.
The wake is best effort and it runs after the tenant db operation.

This only applies to multi-tenant.

Additional context

A failed wake can delay discovery but if feature is enabled, it will be woken eventually.
Adding central store for future dispatch: enroll tenants in batches, claim due tenants and record the result.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[claude]

I didn't find any bugs in this PR. It adds a new central Postgres store with lease-based claim, complete, fail and retire SQL, so a human should still look over the dispatch semantics before merge.

What was reviewed:

• The wake hooks in storage.ts. They run after the tenant DB write, only in multitenant mode, and use a 5s timeout. Failures are logged and not thrown. The versioning wake is gated on the lifecycle-writer-coordination migration.
• wakeTenant upserts with LEAST, so it never moves a due time later. enrollAllTenants pages through tenants by cursor up to max(id). All queries bind their parameters.
• A possible early retire was ruled out. A tenant that uses lifecycle without the per-tenant versioning flag can be removed after its first dispatch, but only if the dispatcher calls retireTenant, and this PR adds no such caller.

Extended reasoning...

The change adds about 250 lines of new multitenant DB store in lifecycle-tenant-store.ts and a small control-plane wake helper wired into Storage.putBucketLifecycle, deleteBucketLifecycle and updateBucket. The rest is roughly 1,300 lines of tests. There is no auth, crypto or permissions surface, and every SQL statement uses bound parameters. I deferred because the claim, lease-expiry, backoff and retire queries set the semantics for a future dispatcher that isn't in this PR, and the whole tree is owned by a CODEOWNERS team.

[coveralls]

Coverage Report for CI Build 42919388890

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage increased (+0.03%) to 87.646%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: 31 of 31 lines across 3 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	16094
Covered Lines:	14547
Line Coverage:	90.39%
Relevant Branches:	10214
Covered Branches:	8511
Branch Coverage:	83.33%
Branches in Coverage %:	Yes
Coverage Strength:	1357.45 hits per line

---

💛 - Coveralls