shadowdaoandClaude Opus 5
b23644fa3e
Build / macOS (macos-latest) (push) Successful in 51s
Build / Linux (ubuntu-24.04) (push) Successful in 1m14s
Build / macOS (macos-latest) (pull_request) Successful in 48s
Build / Linux (ubuntu-24.04) (pull_request) Successful in 1m8s
Build / Windows (windows-latest) (push) Successful in 3m56s
Build / Windows (windows-latest) (pull_request) Successful in 3m56s
Setting WINHTTP_OPTION_RECEIVE_RESPONSE_TIMEOUT (previous commit) fixed the original failure -- the request is now always cancelled instead of waiting out a stall and returning 200 -- but the instrumented CI probe shows it is not cancelled on TIME. Five attempts with a 700ms budget against a server that accepts and then stalls 5s returned after 1490, 1529, 2485, 3493 and 4506ms, every one of them ERROR_WINHTTP_TIMEOUT (12002). One exceeded the test's 4s bound, which is why Windows CI was still red. That is the documented behaviour, not a mystery: both receive timeouts are "checked only when data is received from the socket", so an expired timeout is not surfaced until the peer sends something. Neither option is a deadline. It matters because `fetchSlots` is called synchronously on the OBS UI thread, behind the properties dialog's "Refresh camera list" button (obs-adapter/src/plugin-main.cpp:486, kPropertiesTimeoutMs = 5000). At the overshoot ratio measured above, a stalling server freezes that dialog for something like half a minute -- the exact failure the shortened timeout there was chosen to avoid. So: a watchdog thread that closes the request handle once the deadline passes, which is the documented way to cancel a WinHTTP operation. `RequestDeadline` owns the handle and both threads close it through an `atomic::exchange(nullptr)`, so exactly one close ever happens. Failures are reported as a timeout rather than as a raw GetLastError when the deadline is what fired. The ceiling is twice the caller's budget, not the budget itself: resolve, connect, send and receive each get `timeout` from WinHttpSetTimeouts, so a slow-but-progressing exchange can legitimately exceed one budget and must not be cancelled. There is one accepted race, documented at the class: the caller can load the handle just before the watchdog closes it, turning the call into ERROR_INVALID_HANDLE instead. Both mean the deadline expired. Cross-compiled with mingw-w64 (`-fsyntax-only`) rather than waiting on CI to find syntax errors; also confirmed by preprocessor probe that WINHTTP_OPTION_RECEIVE_RESPONSE_TIMEOUT is defined in those headers, so the #ifdef guard is not silently skipping the option. Linux: all 6 suites pass. Real verification is the Windows job's probe output. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9