Repository navigation
v2 tests: process and project-copy tests flake in CI #37321
Description
Description
The V2 Core unit suite intermittently fails in unrelated platform tests under full CI load:
- Linux:
AppProcess > run > fiber interruption cleans up the scoped child process after readiness - Windows:
ProjectCopy > refresh ignores stale git worktree registrations
Both failures occurred in the same otherwise-successful PR run. Rerunning only the failed jobs passed on both platforms, confirming that the failures are intermittent.
Plugins
Not applicable; this occurs in repository unit tests.
OpenCode version
V2 development branch, observed at PR head 99c20f8886.
Steps to reproduce
- Run
GITHUB_ACTIONS=false bun turbo testin GitHub Actions. - Run the complete Core suite concurrently with the rest of the workspace.
- Repeat until either timing-sensitive failure occurs.
Expected Behavior
The Core unit suite should pass deterministically on Linux and Windows.
Actual Behavior
packages/core/test/process/process.test.ts:187 read the readiness file as an empty string immediately after it appeared:
Expected: /^\d+$/
Received: ""
waitForFile retries only ENOENT; it can observe the file after creation but before its contents are visible.
Windows failure:
https://github.com/anomalyco/opencode/actions/runs/29457042536/job/87492415606
ProjectCopy > refresh ignores stale git worktree registrations
test timed out after 5000ms
The test creates two Git worktrees and refreshes project-copy state under a fixed five-second timeout, which can be exceeded under Windows CI load.
Rerun results:
- Linux passed: https://github.com/anomalyco/opencode/actions/runs/29457042536/job/87495925450
- Windows passed: https://github.com/anomalyco/opencode/actions/runs/29457042536/job/87495925443
Screenshot and/or share link
Not applicable. See the linked GitHub Actions logs.
Operating System
GitHub Actions Linux and Windows runners.
Terminal
Not applicable.
Activity
rasitakyol commentedon Jul 16, 2026
I can take this as a scoped test-only fix. I plan to make the process test PID-file helper retry when the file exists but is still empty, and add a 15s timeout only to the expensive stale-worktree project-copy test. I will include repeated targeted runs and the core typecheck in the PR. Please let me know if you would prefer a different timeout.
bunnysayzz commentedon Sep 9, 2026
The flaky helper is still byte-identical on current
dev, so I put up #48205 with a test-only fix:waitForFilenow waits for non-empty contents (covers theReceived: ""race on the readiness/settled files), and the stale-worktree test gets a 15s timeout for loaded Windows runners. Prior attempt #37377 did the same two things but was closed unmerged without review, so this re-applies them fresh. Targeted suites pass repeatedly (24x3 process, 13x3 project-copy) andpackages/coretypechecks clean.dat-rd commentedon Oct 17, 2026
Both reported failures look addressed on
devnow, so I believe this can be closed.AppProcess > run > fiber interruption cleans up the scoped child process after readiness— thewaitForFilehelper (packages/core/test/process/process.test.ts:26) already waits for non-empty contents (if (contents) return contents) and retries on anything other thanENOENT, and the fixture child publishes its pid through a.tmp→ final rename (:21-24). That is the fix #48205 proposed, and it landed in #43522 (merged 2026-08-19).ProjectCopy > refresh ignores stale git worktree registrations— the test now carries an explicit 15s timeout (packages/core/test/worktree.test.ts:667), andpackages/coreruns its whole suite with--timeout=30000(packages/core/script/test.ts:39, #55866), so the reported 5000ms budget no longer applies.On current
dev(ae6a706) I ran both with--timeout=30000: the worktree case passed 5/5 consecutive runs, the process case 6/6. I also went through the last 12 failedtest.ymlruns and neither test appears in any of them — those failures are ine2e (windows)on branches whosee2e/smoke/directory was removed in #52369.If either one flakes again, a fresh log from the failing shard would be worth more than a third patch, since the time budget has moved since the original report.