ci: timeout-minutes is 20 for a job that now takes 35 seconds, so the ceiling no longer guards anything

[ivndev001]

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-minutes is 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 timeout in install chromium are 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.

[developerz-ai]

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.yml on main: timeout-minutes: 20 on the single bun job, 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

• files: .github/workflows/ci.yml only
• reduce timeout-minutes to a value that still exceeds the legitimate worst case, and replace the stale rationale comment with the measured runtime + retry budget + chosen headroom
• PR body states the measured job duration and the headroom over the worst legitimate case
• retry/backoff and the 300s per-attempt timeout in install chromium untouched
• no test skipped, weakened or removed; CI green on the PR itself

One tension to put on the record before a number is picked

The worst legitimate install chromium is 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-minutes on the steps that should be fast (lint, typecheck, test, build, verify launch): a wedged bun test then 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]

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_consent reached 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:

• Scope: .github/workflows/ci.yml only. Nothing else.
• Change: reduce timeout-minutes on the bun job 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.
• Hard floor: install chromium worst 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.
• Untouched by design: the retry/backoff and the 300s per-attempt timeout, the tests, and bun-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]

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-minutes on 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]

Plan issue #79 in developerz-ai/ui-debugger-mcp

• Picked up
• Surveying the repo
• Working
• Pull request opened
• Done

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]

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.