shadowdaoandClaude Opus 5
8888e57d08
Build / macOS (macos-latest) (push) Successful in 50s
Build / Linux (ubuntu-24.04) (push) Successful in 1m14s
Build / macOS (macos-latest) (pull_request) Successful in 49s
Build / Linux (ubuntu-24.04) (pull_request) Successful in 1m16s
Build / Windows (windows-latest) (push) Failing after 3m55s
Build / Windows (windows-latest) (pull_request) Failing after 3m51s
Two things, both prompted by an intermittent Windows CI failure in
test_api_client's testPlatformBackendTimeout: roughly 2 runs in 6, both its
assertions failed together, meaning a request with timeout_ms=700 waited out a
5s server stall and returned 200. Same failure on 2026-09-07 (job 5834) and
2026-09-09 (job 5911), on code that passed on other runs -- pre-existing and
intermittent, not caused by a change.
1. The real bug. `WinHttpSetTimeouts`' receive parameter maps to
WINHTTP_OPTION_RECEIVE_TIMEOUT, which Microsoft documents as a PER-PACKET
Winsock-layer read timeout ("applies to fetching each packet of data off
the socket"). The wait for the response HEADERS is a separate option,
WINHTTP_OPTION_RECEIVE_RESPONSE_TIMEOUT, which WinHttpSetTimeouts does not
set and which defaults to 90 SECONDS. So a server that accepts, reads the
request and then stalls could block the calling thread for a minute and a
half no matter what the caller passed as timeout_ms -- precisely the
"blocking an OBS thread indefinitely" failure that test exists to prevent.
Now set explicitly, guarded by #ifdef so an older SDK still builds.
That is a genuine defect on its own merits. Whether it is the whole
explanation for the intermittency is NOT established: the same docs say
this timeout "is checked only when data is received from the socket", so
neither option guarantees a hard deadline -- that needs a watchdog calling
WinHttpCloseHandle, deliberately not done here.
2. Evidence, so the next run says more than pass/fail. The probe now runs 5
times and prints elapsed ms, ok, status, requests_seen and the backend's
error string (carrying GetLastError) for every attempt, so one CI run
yields a failure RATE and an error code. Each attempt gets a FRESH
loopback server: the server handles one connection at a time on a single
thread, so reusing it would leave attempts 2..n in the accept backlog --
never accepted, a different scenario from the one that fails. Verified on
Linux: 5/5 attempts give up at ~701ms.
Also: build.yml now has paths-ignore for **.md, LICENSE, NOTICE, and the two
release-only files. This is a full three-platform build behind a runner with
capacity:1, and six of them fired for one afternoon of documentation edits.
Nothing that feeds a build or a test is on that list. Tradeoff: a docs-only
push now shows no status at all rather than a green one.
The WinHTTP change cannot be compiled locally (Linux host); CI is its first
build. All 6 suites pass locally on Linux.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9