[ferhatelmas]

What kind of change does this PR introduce?

feature

What is the current behavior?

Lifecycle policies and the execution engine exist but nothing automatically schedules lifecycle runs.

What is the new behavior?

A scheduler dispatches due tenants and bucket jobs to evaluate lifecycle policies and clean up abandoned deletion artifacts. In multitenant mode, tenant feature flag or policy changes can wake an enrolled tenant.

The global versioning flag enables lifecycle processing but does not enroll every tenant because it's intended to be enabled by default.

STORAGE_LIFECYCLE_PAUSED=true pauses scheduling while leaving policy APIs available.
Failed or expired dispatches are retried and bucket run duration is recorded.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coveralls]

Coverage Report for CI Build 43104836491

Coverage increased (+0.09%) to 87.737%

Details

• Coverage increased (+0.09%) from the base build.
• Patch coverage: 147 of 147 lines across 8 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:	16252
Covered Lines:	14700
Line Coverage:	90.45%
Relevant Branches:	10275
Covered Branches:	8574
Branch Coverage:	83.45%
Branches in Coverage %:	Yes
Coverage Strength:	1347.08 hits per line

---

💛 - Coveralls

[claude]

Beyond the inline finding, I also checked the unguarded pre-commit wakeTenant call in withLifecycleConfigurationTransaction (control-plane.ts) — since it runs before the transaction starts, a failure there just aborts the request with no side effects yet, unlike the post-commit call which is wrapped in try/catch because it runs after data is already committed. I also checked the new S3-backend startup validation that requires STORAGE_LIFECYCLE_CLAIM_LEASE_MS to exceed the S3 client timeout plus recovery grace when STORAGE_VERSIONING_ENABLED is on — this is an intentional safety gate against unsafe destructive-lifecycle configs on S3, not an accidental crash.

Extended reasoning...

One confirmed finding (the STORAGE_LIFECYCLE_ENABLED to STORAGE_VERSIONING_ENABLED rename with no back-compat alias) is already being posted inline, so this note only adds the ruled-out context. I re-read control-plane.ts and confirmed the pre-commit wakeTenant call is unguarded but runs before any transactional side effects occur, so a failure there is a clean abort rather than a partial-commit hazard — different in kind from the post-commit call, which is deliberately wrapped in try/catch because side effects are already committed by that point. I also read the config.ts validation block and confirmed the STORAGE_VERSIONING_ENABLED + S3 backend check is a deliberate startup guard (requiring a sane claim-lease/timeout relationship) rather than an unintended crash path.

[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]

Code review found no issues

No high-confidence issues detected in this change.