Repository navigation
CI: opencode.contract "pages a long session" times out on unrelated PRs #1076
Description
What happens
server/opencode.contract.test.ts "pages a long session, and answers 409 for a cursor from another history" times out (15 s) on CI and then fails its ordering assertion at line 122, on PRs that do not touch OpenCode:
- fix(auth): cap shared failure bookkeeping #1059 (auth) run 38549480053
- fix(chat): hold pending input after process replacement #1069 (pending input) run 38552340736
- fix(plugin): wait for the Windows process tree to exit #1074 (plugin, Windows process tree) run 38555963748
Each passed on gh run rerun --failed (#1059, #1069). The failing assertion is an toEqual on the paged message list ("Check chat", "Check again", "p0", "p1", ...), and the test ran 17-22 s against its 15 s limit.
Where
server/opencode.contract.test.ts:122- Integration lane,
Integration tests (updater restart and rollback included)
Notes for a fix
Not investigated yet. The time (17-22 s) suggests the long-session fixture plus paging reads are slow under a loaded runner; whether the assertion failure is a consequence of the timeout or a separate race is not known.
Activity
devswha commentedon Oct 14, 2026
Seen again on #1061 (tab switch cache; no OpenCode change): run 38554647922, same assertion at server/opencode.contract.test.ts:122 after 16 s. That is four unrelated PRs today (#1059, #1061, #1069, #1074).
devswha commentedon Oct 14, 2026
Seen again on #1085 (terminal grid handoff; no OpenCode change): run 38561817669, this time at server/opencode.contract.test.ts:118 (a cursor came back undefined) after 16.7 s.
test(opencode): isolate paging from later fixture changes (#1100)
devswha commentedon Oct 14, 2026
Fixed by #1100 (70f48c4).
Verification: 10/10 consecutive in one check run, plus an independent review (VERDICT: confirmed). Reopen if the test times out again on CI.
devswha commentedon Oct 14, 2026
Reopening on the independent reviewer's advice. #1100 fixes the misleading ordering failure (fixture contamination). It does not prove the 17-22 s stall is gone: batching the fixture is the likely fix but was not measured on CI. Keep this open until the test has run clean on CI for a while; if it times out again, the failure is now a plain timeout and no longer a toEqual diff. The assertion moved from line 122 to line 139.
devswha commentedon Oct 17, 2026
Closing: since #1100 (70f48c4) the paging test has not failed on CI. I checked the logs of all 48 failed CI runs since 2026-10-14; in each it passed in 2-4 s. If it times out again, the failure is now a plain timeout and this can be reopened.