Repository navigation
Completed Application warm runners exhaust CF memory and block releases #147
Description
Application executions dispatched through the warm pool leave consumed one-shot CF apps behind after their final result. runner_pool_size=1 limits standby slots, but consumed Application slots are excluded from that capacity count and only probe/platform cleanup currently removes them. CF restarts the one-shot web process, retaining its memory allocation.
Observed in Dev: ten warm apps consumed the full 10 GiB organization quota; the next release could not stage its Runner template because staging needed another 1 GiB. The existing app and current Runner droplet remained aligned.
Required fix and acceptance:
- Retire only durably completed (
succeeded/failed) Application dispatches with exact job, app and source-droplet binding. - Preserve running jobs, ambiguous/reconciliation cases, state and saved plan artifacts. Expiry alone is insufficient.
- Reuse the existing scoped CF removal path, retaining retryable leases on cleanup failure.
- Cover authorization and binding failures with real database regressions.
- Safely reconcile historical completed apps, then verify a Dev deployment and a pool of one standby without accumulating completed runners.
No customer Plan/Apply, force unlock or state deletion is part of this issue.
Activity
fix(runner): clean up completed Application pool runners (#148)
lweberru commentedon Oct 23, 2026
Resolved by #148 and deployed to Dev in release 39974933974, source
1f7b2da8bd175257983213329a212b932c0bac04.Live verification after deployment:
Validation: full Configurator check (1056 passed, 71 gated skips), real PostgreSQL identity/pool regressions, final focused pool suite (12 passed), platform database suite (63 passed), and 328 desktop/mobile browser tests. The initial CI attempt timed out after an 8m11s OS dependency download; the unchanged-source retry completed the full suite, as documented in the PR.
The explicit Dev mode skipped Assistant live qualification; the Assistant remains enabled and normal qualified-release gates are unchanged. No customer Plan/Apply, State change or unlock was performed as part of this fix.