create_app: the dispatcher's bootstrap races a manual create_app; the 5-min CI wait is short for a cold runner #210

New issue

Open

opened 2026-08-25 15:59:24 +00:00 by plat · 0 comments

plat commented

2026-08-25 15:59:24 +00:00

Owner

Observed twice on a fresh daughter (2026-08-24). (1) A manual create_app and the dispatcher's own bootstrap (repository.created → maybeBootstrap) both run create_app for the same repo; both try to create the v0.1.0 release and one fails with Forgejo UQE_release_n (duplicate). Self-heals via the dispatcher's transient retry, but the manual caller gets a confusing error. Options: treat the 409/duplicate as convergence (like the 422 registry-team ensure in 0.42.2), or have the dispatcher skip bootstrap when a create_app for the key is already in flight. (2) waitForCI caps at 5 min; a cold isolated runner (buildkit cache empty, oven/bun pull) needs ~10 min on a 6-vCPU node, so create_app/release_app time out and must be re-issued (re-join works). Consider a longer first-build budget or polling that returns the run URL and lets the caller re-issue without the timeout reading as failure.

Observed twice on a fresh daughter (2026-08-24). (1) A manual `create_app` and the dispatcher's own bootstrap (repository.created → maybeBootstrap) both run create_app for the same repo; both try to create the v0.1.0 release and one fails with Forgejo `UQE_release_n` (duplicate). Self-heals via the dispatcher's transient retry, but the manual caller gets a confusing error. Options: treat the 409/duplicate as convergence (like the 422 registry-team ensure in 0.42.2), or have the dispatcher skip bootstrap when a create_app for the key is already in flight. (2) `waitForCI` caps at 5 min; a cold isolated runner (buildkit cache empty, `oven/bun` pull) needs ~10 min on a 6-vCPU node, so create_app/release_app time out and must be re-issued (re-join works). Consider a longer first-build budget or polling that returns the run URL and lets the caller re-issue without the timeout reading as failure.