Repository navigation
fix(ci): stop windows search-endpoints failures and cap the exerciser step - #28
Merged
Merged
Conversation
… step The windows unit job has failed every main run since the workflow went green post-rebrand, always on "file HttpApi > serves search endpoints" at ~30s: the file-search index needs ripgrep, whose first use downloads and extracts the binary, and on GitHub-hosted Windows runners that alone can eat the whole 30s poll bound (ripgrep.test.ts already runs with 120s timeouts for the same reason). Give the poll 120s and the test an explicit 150s timeout; the poll still returns the moment the index is ready. Also cap the HttpApi exerciser step at 30 minutes: the three modes normally finish in a few, but a wedged effect-mode run (seen once on main) otherwise holds the job until GitHub's 6-hour ceiling because the step had no timeout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The 120s poll bump was not enough: the search-endpoints test now fails
at ~120.7s, meaning the file-search index never becomes ready at all.
Root cause: the index is populated by a background ripgrep --files walk
forked with Effect.orDie (core/src/filesystem/search.ts), so when the
first-use download+extract of rg.exe fails or stalls on GitHub-hosted
Windows runners, the failure is swallowed and findFile returns an empty
list forever. Pre-installing ripgrep via choco makes binary.ts's
which("rg.exe") short-circuit the download, removing the fragile step
from the test path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
testworkflow has never been green onmain. Since #24 cleared the rebrand breakage, the one consistent failure isunit (windows)→file HttpApi > serves search endpoints, failing at ~30s on every run (#24, #26, #27). Separately, the #27 run exposed a second problem:unit (linux)hung inside the HttpApi exerciser (effect mode) for 2+ hours because that step has no timeout.Search-endpoints fix. The file-search index needs ripgrep, and ripgrep's first use downloads and extracts the binary — on GitHub-hosted Windows runners that alone can consume the whole 30s poll bound (this repo already runs
ripgrep.test.tswith 120s timeouts for exactly this reason; see the DIVERGENCES row). The poll bound goes 30s → 120s with an explicit 150s test timeout (bun's CLI default is 30s, which was also firing). The poll still returns the instant the index is ready, so the test stays fast off CI and hang regressions are still caught.Exerciser cap.
Run HttpApi exerciser gatesgetstimeout-minutes: 30. The three modes normally finish in a few minutes; the effect-mode wedge on #27's run was not reproducible locally (coverage/auth/effect all pass 208/208 on this commit and its parent), so it's treated as a runner flake — but a recurrence should cost 30 minutes, not 6 hours.DIVERGENCES.md rows for both files updated.
Test plan
bun test test/server/httpapi-file.test.tsfrompackages/opencode— 2/2 passbun typecheck— cleanunit (windows)job is the real validation for the timeout bump