Repository navigation
Flaky on Windows: session remove in SessionPermissionRulesLiveTests' cleanup got no response within its bound #346
Description
What
Master CI on 341a63ed (the #343 merge), run 38803551256, failed on the Windows leg, net10.0 (OpenCode.Sdk.Tests, 2509 passed, 1 failed). The failing test was SessionPermissionRulesLiveTests.PutPermissionRulesAsync_Should_Replace_The_Session_Ruleset, after 15.0 s:
TaskCanceledException: The operation was canceled.
at OpenCode.Sdk.Tests.Sessions.SessionPermissionRulesLiveTests.CleanupAsync(SessionClient session, Exception primaryFailure)
in tests/OpenCode.Sdk.Tests/Sessions/SessionPermissionRulesLiveTests.cs:84
---> IOException: Unable to read data from the transport connection: The I/O operation has been aborted …
- The test body succeeded. Its assertions passed, so
primaryFailurewas null. - The cleanup failed.
session.RemoveAsync()was cancelled by the cleanup's ownCleanupTimeout, while still waiting for the response toDELETE /api/session/{id}. Because there was no primary failure, the cleanup's exception became the test's failure. - Not caused by perf: the generator's own benchmarks for the before-refactor baseline (#186) #343, which changes only the performance project and quality-gates.md.
Why it may matter
A request to a running server that gets no response within seconds also appears in #333: a first config.get hung for 60 s on Windows CI. That one had no server-side evidence. Since #345 (abb11393), a failed pinned-server test uploads the server's own log, so the next occurrence of either should show what the server was doing.
Next
Recorded under the flake rule before the re-run. No retry, wider bound or quarantine. Root cause first, from the server log of the next occurrence.
Activity
Blind-Striker commentedon Oct 15, 2026
Possibly the same family as #333: on Windows CI, a request to a running pinned server gets no complete response within its bound. Here it was
DELETE /api/session/{id}, whose response read was aborted at 15 s; in #333 it was a firstconfig.get, which hung for 60 s. This occurrence ran at341a63ed, before #345's capture, so it has no server log. If the next occurrence of either, now uploadingserver-logs/, shows the same server-side stall, the two are one root cause, tracked together. No fix for either until those logs are in.Blind-Striker commentedon Oct 15, 2026
The failed-jobs rerun of run 38803551256 (attempt 2, same commit
341a63ed) passed on Windows. So this is intermittent, not a regression of that commit. The issue stays open until a captured occurrence explains it.Blind-Striker commentedon Oct 16, 2026
Seen again on the Windows CI leg of #371 (run 38920097587, job 117037511050, 2026-10-16), on both net10.0 and net48, each failing after 15 s. #371 doesn't touch the SDK or the live tests.
The body passed and the cleanup request timed out:
Both frameworks failing within the same minute points at the server's session remove stalling on the Windows runner, not at a per-framework client defect.