[ferhatelmas]

What kind of change does this PR introduce?

feature

What is the current behavior?

Storage can save lifecycle configurations but it has no lifecycle execution state or worker to expire noncurrent versions.
Deleting a bucket does not need to account for an in-flight lifecycle batch.

What is the new behavior?

• Add bucket and tenant state for scheduling, claims, progress and recovery.
• Create or update that state when policies change or versioning is enabled and backfill existing policies.
• Preserve in-flight work across policy changes and block bucket deletion while it needs recovery.
• Add a function for deleting eligible archived metadata and a table for recording backend artifacts that could not be deleted.
• Add indexes and tests for upgrades, re-runs and concurrent transactions.

Additional context

This provides the schema, not the lifecycle worker.
Expiration of backend objects begins only after the engine and its required versioning integration are in place.
Multipart rules aren't integrated and will come up as a follow up.

Related to #1380

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[coveralls]

Coverage Report for CI Build 40898949198

Coverage increased (+0.09%) to 86.887%

Details

• Coverage increased (+0.09%) from the base build.
• Patch coverage: 3 uncovered changes across 1 file (35 of 38 lines covered, 92.11%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
src/test/utils/lifecycle-versioning.ts	34	31	91.18%
Total (2 files)	38	35	92.11%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	15546
Covered Lines:	13950
Line Coverage:	89.73%
Relevant Branches:	9880
Covered Branches:	8142
Branch Coverage:	82.41%
Branches in Coverage %:	Yes
Coverage Strength:	1212.72 hits per line

---

💛 - Coveralls

[ferhatelmas]

@claude review always

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

I re-reviewed the latest push and found no new bugs. Both earlier inline points look addressed. This is still a large schema change with SECURITY DEFINER functions and a trigger on the multitenant tenants table, so a human look would still be worthwhile.

What was reviewed:

• OrioleDB wake path: both wake triggers now call reconcile without comparing OLD and NEW images, and policy changes are detected from the generation stored in the state row.
• reconcile_lifecycle_state now treats a continuation as idle only under the same version-1 predicate the bucket-delete guard uses, so continuations it can't read are kept and only woken.
• Grants and revokes on the new SECURITY DEFINER functions (search_path pinned to pg_catalog, PUBLIC revoked, roles resolved from storage.* settings).

Extended reasoning...

The change adds about 2,600 lines: a multitenant migration with a lifecycle_tenants table and an enroll trigger on public.tenants, four tenant migrations (a state table, two concurrent indexes, and the writer-coordination triggers and functions), and large integration test suites. The security-sensitive surface is the new SECURITY DEFINER functions (reconcile_lifecycle_state, wake_lifecycle_state, delete_lifecycle_objects) and their role grants, plus a BEFORE DELETE guard on storage.buckets. The latest commits appear to fix both issues raised earlier in inline comments. I deferred rather than approved because of the size, the privileged functions, and the design choices about locking, recovery and continuation semantics, which deserve a maintainer's judgment.

[claude]

1 optional suggestion (a nit or a note on pre-existing code) was found and not posted.

[claude]

No new blocking issues. 1 optional suggestion (a nit or a note on pre-existing code) was found and not posted.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[ferhatelmas]

multigres/multigres@a7a65bf

seems previous commit broke the multigres image, and this is fixing. In the meantime, multigres CI failed

[TylerHillery]

Approving with one nit feedback and one question. The question around the service role calling that storage.delete_lifecycle_objects I don't think is a major concern as given service roles already can set storage.allow_query and do what they want but just wanted to make sure that service role callers could theoretically call this function with any archived object id without it be eligible for deletion by a lifecycle rule.

[claude]

Code review found no issues

No high-confidence issues detected in this change.