ci: bun-version: latest silently took CI from 2s to 30s on a 30s ceiling — main is red and every PR is a coin flip

[ivndev001]

The problem

ci.yml pins bun-version: latest. Bun shipped 1.4.2, and one test went from ~2 s to ~30 s against a 30,000 ms ceiling. CI on this repo is now red most of the time, on every branch, including main.

a persona whose credentials are wrong fails the run instead of opening it signed out (src/services/session-builder.test.ts, ceiling STORY_TIMEOUT_MS = 30_000), duration taken from each run's own log:

run	commit	bun	duration	result
30590216643	e095c5f1	1.3.x	2,040 ms	pass
31234293242	b81f3861	1.3.x	1,864 ms	pass
31238151616	d8affa0b	1.3.14	1,962 ms	pass
33641952951	9c5a7541	1.4.x	30,018 ms	FAIL
33645730932	f4cb7059	1.4.x	29,582 ms	pass
33647731476	06ec3a07	1.4.x	30,027 ms	FAIL
33962322833	45abb1a8	1.4.x	30,019 ms	FAIL
33963265619	e032d666	1.4.x	29,955 ms	pass
33963665479	fdb4db4e	1.4.x	30,036 ms	FAIL
33964715003	45abb1a8	1.4.2	29,772 ms	pass
33965471840	77081f8d	1.4.2	30,016 ms	FAIL

Plus five more failures on 77081f8d from re-runs, all 30,0xx ms.

Two things this table settles:

1. It is not intermittent. Every 1.4.x run takes 29.6–30.0 s. The "passes" win by 30–420 ms under the ceiling. That is noise, not health, so a green run is not evidence the test is fine.
2. The break is the toolchain, not a commit. The last fast run is 1.3.14 on 2026-08-08; every 1.4.x run is slow. 9c5a7541 (the first slow one) is a config-loader branch that cannot plausibly make a login test 15x slower, and the two commits blamed since — 06ec3a07's dual-read and e032d666's 5 s settle cap — are both exonerated by it. e032d666 measured 29,955 ms against an uncapped 30,019 ms the same day: a 64 ms delta from capping a wait by 25,000 ms, which is how we know that wait is not where the time goes.

Why it matters

Every PR here is a coin flip, and the odds are bad: 2 of 8 recent attempts passed. Release PR #69 has burned nine CI runs without a merge. main is red. The failure mode also teaches the wrong lesson — the natural response to "flaky, passes on re-run" is to re-run until green, which merges code whose suite sits 30 ms from the edge.

What to do

Two parts, in order.

1. Pin the toolchain. bun-version: latest means the gate can change under the repo with no commit and no review. Pin it to a known-good version and bump deliberately. That alone restores a deterministic CI and unblocks the release.
2. Then diagnose the 28 s. Do not raise STORY_TIMEOUT_MS and do not quarantine the story — the test would then pass over a path that still takes 30 s, which converts a visible regression into an invisible one. Something in 1.4.x makes this path slow; it is worth knowing what, because it is a real 15x slowdown in the product's login path on the runner, not only in the test.

Note this does not reproduce locally on bun 1.3.14, where the test runs in 3.2–4.1 s. Reproducing it needs 1.4.2.

Acceptance criteria

• ci.yml names an exact bun version rather than latest
• ten consecutive CI runs on main are green, with the persona test well under its ceiling rather than within 500 ms of it
• STORY_TIMEOUT_MS is unchanged and the story is not skipped or quarantined
• the 1.4.x slowdown is either explained or has its own follow-up issue

Found by

Cutting release 1.9.0 (#69), which is blocked behind this.

[ivndev001]

Also worth recording: this exonerates two changes that were blamed for the redness.

PR #67's second commit e032d666 caps a post-submit settle wait at 5 s and states in its changelog that this is why CI was red on main. Measured against the uncapped baseline the same day, capping a wait by 25,000 ms moved the test by 64 ms (29,955 ms vs 30,019 ms), and an uncapped commit ran 374 ms faster than the capped one. A DEBUG=pw:api trace on main shows waitForLoadState resolving 8 ms after the click. So the settle wait is not where the time goes, and that claim should not ship in release notes.

The cap also has a cost in the other direction: capWait only shortens and no config knob raises it, so the settle wait becomes a hard 5 s for every consumer, down from up to 30 s. A login whose navigation commits between 5 s and 30 s then reports "still on ... the login did not take. Check the credentials and the field keys" — correct credentials diagnosed as wrong. That is the documented default path, since the README's persona example omits expect and only the expect branch keeps the full budget.

Release #69 therefore takes #67's first commit alone. #67 stays open for the login change, which needs its own diagnosis now that the real cause is known.

[developerz-ai]

🤖 developerz.ai maintainer bot — developerz-ai[bot]

Tracking pull request #71 for this issue.

[ivndev001]

Diagnosis complete. The 2x2 is filled and it says there are two independent regressions, not one.

code	bun 1.3.14	bun 1.4.2
pre-dual-read (d8affa0b)	both fast — 1,962 ms / 808 ms	wrong-cred 30,004 ms, signs-in 802 ms
post-dual-read (main)	wrong-cred 2,045 ms, signs-in 30,008 ms	wrong-cred ~30,000 ms, signs-in ~800 ms

Cells, with their runs: top-left 31238151616 / 31234293242 / 30590216643; top-right the throwaway probe in #72; bottom-left the two pinned runs on #71; bottom-right 33647731476, 33963265619, 33964715003, 33965471840.

The history alone could not say which variable mattered, because every pre-dual-read run happened to use 1.3.x and every post-dual-read run 1.4.x. The two probes break that confound and each variable turns out to be independently sufficient:

1. bun 1.4.x makes wrong-cred hang, on the OLD tree as well as the new one. The dual-read is exonerated for this one, and so is chore: release v1.9.0 — .dz/ dual-read config resolution #67's settle cap.
2. The dual-read commit makes signs-in hang on 1.3.14, where the pre-dual-read tree ran it in 808 ms. This one is new information and it is not a toolchain problem.

Every hang is 30,00x ms — LOGIN_TIMEOUT_MS to the millisecond — and exactly one of the two stories hangs per run, never both. Two unrelated perturbations each cause a full-budget stall in performLogin, and which story absorbs it tracks the perturbation. That points at one fragility in the login path with two triggers, rather than two separate bugs.

Practical consequence: pinning to 1.3.14 is worse, not better, and #71 should not merge. On 1.4.2 the wrong-cred hang clears its ceiling occasionally, 2 of 8 runs. On 1.3.14 the signs-in hang measured 30,008 ms and 30,010 ms with no margin at all, 2 of 2. The pin trades an occasional failure for a reliable one.

The thing worth someone's afternoon is why performLogin can consume its entire budget at all. Both triggers found so far are incidental; a third will come along.