Repository navigation
Live VCS status/diff test on Windows: 'connection forcibly closed by the remote host' #472
Description
VcsClientLiveTests.GetStatusAsync_And_GetDiffAsync_Should_Report_A_Modified_Tracked_File failed once on the Windows CI leg (net10.0). Its pinned live server dropped the connection mid-request.
Observation
-
Run: CI run 39077427835, job Build & Test (Windows), on PR fix(generator): a curated hoisted member is called optional only when it is #468 at head
80ddef3e(2026-10-17 23:12 UTC). -
Test:
tests/OpenCode.Sdk.Tests/Vcs/VcsClientLiveTests.cs:73, onOpenCode.Sdk.Tests.dll (net10.0|x64); 10.5 s to failure. -
Error:
[Test Failure] OpenCodeTransportException: The opencode server could not be reached. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.. -
Unrelated to the PR: PR fix(generator): a curated hoisted member is called optional only when it is #468 is tools-only, and its generated output is byte-identical (
generate --verifycurrent). On the same run:- Linux, macOS, lint and CodeQL are green;
- the Windows leg's other test assemblies passed, including Tools.Tests at 2089/0;
- this was the only failure in
OpenCode.Sdk.Tests.
-
Rerun: I reran the failed job after filing this record. The rerun's result will be added here.
Owner and suspected area
- Owner: Runtime, as owner of the live-server harness.
- Possible shared root: Session removal can exceed its 15 s cleanup deadline on the Windows net472 leg (GetLogAsync cursor-past-tail test) #466 (session removal exceeding its cleanup deadline on Windows). Both are Windows live-server timing or cleanup failures under CI load; a server that is ending or restarting would close an in-flight connection the same way.
- What would settle it: the retained server log for this test from the run's artifacts, which would show whether the server exited, restarted or reset the socket at that moment.
Activity
Blind-Striker commentedon Oct 17, 2026
Rerun result: the rerun of the failed Windows job in run 39077427835 (same head
80ddef3e, no code change) passed,VcsClientLiveTestsincluded. So this is an intermittent failure, not a deterministic one on that head.Blind-Striker commentedon Oct 18, 2026
Targeted probe: not reproduced.
Setup: a client against the pinned server (2.0.32) on Windows. Each attempt makes one request, waits a delay
daround the server's idle close, and then reuses the connection. There were six delays from T−200 ms to T+50 ms, 10 attempts each, on net10.0 and on net472. A second client with a shorter idle timeout served as the control.Connection: keep-aliveandKeep-Alive: timeout=5.Gap found. The SDK sets no idle timeout. The modern transport sets only
PooledConnectionLifetime(120 s), so the default 60 s idle applies; net472 sets noServicePoint.MaxIdleTime. A pooled connection can therefore outlive the server's 5–6 s idle close.HttpRequestException, which matches this failure.Upstream's first-party client (undici under Node) honours the
Keep-Alivehint minus 2 s, so it does not reuse a connection idle for more than about 3 s.Next: an idle timeout below the server's hint, as parity hardening, is with the maintainer. It is not claimed as a proven fix for this failure. This issue stays open under #506 until that decision.