Repository navigation
ci: timeout-minutes is 20 for a job that now takes 35 seconds, so the ceiling no longer guards anything #79
Description
What is wrong
.github/workflows/ci.yml declares timeout-minutes: 20 for a job that now finishes in about 35
seconds. A ceiling 30-odd times the real runtime is not a guard — it will not catch a regression
that takes the job from 35 seconds to five minutes, which is exactly the kind of regression this
repo has already had twice.
Why it is 20, and why that reason is gone
I raised it myself in #77, and the justification was accurate at the time: the job was being killed
at the old timeout-minutes: 10 while bunx playwright install-deps chromium crawled through an
apt fetch (measured: 150 kB/s, one attempt failing outright with exit 100, one run cancelled at
10m17s). 20 was chosen to fit a full failed-then-retried apt cycle.
That cause no longer exists. The same PR removed the apt path entirely — the install now pulls the
browser from Playwright's CDN over HTTPS using the repo-pinned playwright-core CLI. Post-merge
timings on run 34584382386:
install chromium 7s
verify chromium launches <1s
test 13s
build 1s
whole job ~35s
So the ceiling is now sized for a code path that was deleted.
What to do
Bring timeout-minutes down to something that still tolerates a cold CDN fetch and a slow 2-vCPU
runner, but would actually fire on a real regression. Pick the number from measurement, not from
comfort, and say in the PR body what you measured and what headroom you left.
Two things to keep in mind rather than optimise away:
- The install step retries up to 3 times with 20s/40s backoff and a 300s per-attempt
timeout, so
the worst legitimate case is meaningfully longer than the happy path. The ceiling must fit that
worst case or a transient CDN hiccup becomes a red build. - A cold cache is slower than a warm one. The happy-path 35s is with the Playwright cache hitting.
Acceptance criteria
-
timeout-minutesis reduced, and the PR body states the measured job duration and the headroom
the new value leaves over the worst legitimate case (3 retries at the 300s per-attempt cap) - CI is green on the PR itself — a ceiling that fails its own build is self-refuting
- the retry/backoff and the per-attempt
timeoutininstall chromiumare left alone; this
issue is about the ceiling only - no test is skipped, weakened or removed to fit inside the new ceiling
Notes
Small and low-risk, but it restores a guard that currently detects nothing. Found while repairing
this repo's CI in #77.
Activity
developerz-ai commentedon Sep 11, 2026
Qualified as a bug — the workflow's job ceiling is stale, and a guard that detects nothing is a defect in shipped CI config, not a feature request. I read
.github/workflows/ci.ymlon main:timeout-minutes: 20on the singlebunjob, a comment justifying 20 by the retry math, and no apt path left to justify it. Your description matches.Scoped plan handed to the coding agent
.github/workflows/ci.ymlonlytimeout-minutesto a value that still exceeds the legitimate worst case, and replace the stale rationale comment with the measured runtime + retry budget + chosen headroomtimeoutininstall chromiumuntouchedOne tension to put on the record before a number is picked
The worst legitimate
install chromiumis 3 × 300s + 20s + 40s = 16m0s, and the job ceiling has to cover that or a transient CDN hiccup becomes a red build. Add the rest of the job (~35s warm, a couple of minutes cold-cache) and the floor for a single job-level ceiling is ≈ 18 minutes. 20 → 18 satisfies your acceptance criteria, but it still will not fire on a 35s → 5m regression — the motivation in your first paragraph. One ceiling can't do both jobs, because the retry budget you (rightly) fenced off is what sets its floor.The guard that would actually catch the #66/#70 regression class is per-step
timeout-minuteson the steps that should be fast (lint, typecheck, test, build, verify launch): a wedgedbun testthen fails in minutes while the job ceiling keeps its retry headroom. That's outside "the ceiling only", so I've left it out of this task instead of deciding it for you — say the word and it becomes a follow-up.🤖 Posted by developerz.ai — the maintainer agent, not a human.
developerz-ai commentedon Sep 11, 2026
Fleet dispatch did not go through, so no coding agent has picked this up and I have not marked it as handed off.
The dispatch tool rejected its own required input twice on the same call —
reporter_consentreached validation as a JSON string instead of an object, so the schema refused it before a task was created. That is a platform wiring bug, not something about this issue: retrying the identical call unchanged would just fail identically.What is settled and ready for whoever takes it:
.github/workflows/ci.ymlonly. Nothing else.timeout-minuteson thebunjob and replace the stale rationale comment (it still justifies 20 by an apt path that fix(ci): retry the chromium dependency install and raise the job budget #77 deleted) with the measured runtime, the worst-case retry budget and the headroom chosen.install chromiumworst case is 3 × 300s + 20s + 40s = 16m0s. The job ceiling must clear that plus the rest of the job, so ~18m is the smallest honest single-ceiling value. 20 → 18 is a real reduction and satisfies the acceptance criteria; it will still not fire on a 35s → 5m regression, which is the tension I set out above.timeout, the tests, andbun-version(separate work).Flagged for the maintainer as
ready-for-human. The per-step timeout idea that would actually catch the #66/#70 regression class is still open as a follow-up if you want it.🤖 Posted by developerz.ai — the maintainer agent, not a human.
ivndev001 commentedon Sep 11, 2026
You are right, and the tension is mine — I wrote an issue whose stated motivation its own constraint forbids.
Your arithmetic holds: 3 × 300s + 20s + 40s = 16m for the worst legitimate install, so a single job-level ceiling cannot go below roughly 18 minutes without turning a transient CDN hiccup into a red build. 20 → 18 would satisfy every acceptance criterion I wrote and still not fire on the 35s → 5m regression I gave as the reason for filing. That is a criterion set that can be met without the problem being solved, which is the kind of thing worth catching before the work rather than after.
Proceed with the scoped task as you have it, on the narrow reading: reduce the ceiling to a defensible number, replace the stale rationale, leave the retry and the per-attempt timeout alone. Even at 18 it is better than 20 — the comment stops asserting a justification that no longer exists, and the number stops being sized for a deleted apt path.
And yes, file the follow-up. Per-step
timeout-minuteson the steps that should be fast — lint, typecheck, test, build, verify-launch — is the guard that actually catches the #66/#70 class, and it composes correctly with the job ceiling keeping its retry headroom. That is the fix my first paragraph was reaching for; I asked for the wrong mechanism.One thing for whoever picks up the follow-up: pick each per-step budget from measurement, the way this task is being asked to. The current warm-cache timings are install 7s, verify-launch under 1s, test 13s, build 1s (run 34584382386). A per-step ceiling set from comfort rather than measurement recreates this issue one level down.
developerz-ai commentedon Sep 11, 2026
Plan issue #79 in developerz-ai/ui-debugger-mcp
Finished — the report is on the run timeline.
6m · 2 messages
Sessions: coding run
🤖 developerz.ai maintainer bot — sebby-ovh-3 (developerz-ai[bot])
developerz-ai commentedon Sep 11, 2026
I couldn't reliably complete this request because the model repeatedly produced invalid action parameters. I stopped instead of claiming success; a maintainer will review the recorded session trace.
🤖 Posted by developerz.ai — the maintainer agent, not a human.