playwright: per-request HTTP timeout so a wedged host fails fast (E1)#182
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Playwright/live-API client transport to apply a hard per-request HTTP timeout, so integration tests fail fast (≈10s) when the host wedges and stops responding, instead of hanging until the overall popen watchdog (120s).
Changes:
- Add
http_get/http_posthelpers inimgui_transportthat setHttpRequest.timeoutper request. - Route live API calls in
imgui_playwright(readiness polling, text fetches, and control signals) through these timeout-bounded helpers.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| widgets/imgui_transport.das | Introduces HttpReply, http_get, and http_post wrappers that set per-request timeouts and are used by live_api_transport. |
| widgets/imgui_playwright.das | Switches readiness polling, simple GETs, and signal POSTs to use the new timeout-bounded transport helpers. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The live-API client (live_api_transport's POST /command, plus wait_until_ready / get_text / post_signal) used dasHV's convenience GET/POST, which inherit libhv's default (effectively unbounded) response timeout. The host serves the live API on the GLFW main thread that also advances frames, so when a synth command wedges that thread the host stops answering AND stops rendering — and the client blocks on the POST with no timeout, running the test body all the way to the 120s popen watchdog (DEFAULT_TEST_TIMEOUT_SEC) instead of failing in seconds. Seen on #118 windows-latest: test_imgui_synth_ctrl_shortcuts wedged for 159s and tripped "daslang-live timed out (>120s)". Add http_get / http_post helpers in imgui_transport that build an HttpRequest via the existing request() rail with a hard per-request timeout (DEFAULT_REQUEST_TIMEOUT_SEC = 10s, clamped to 1..65535 so misuse can't wrap the uint16 field), and route every client call through them. A wedged host now yields a null / status-0 reply in ~10s, so the wait_until budgets actually bound the failure and the diagnostic is legible instead of a mute 120s hang. Client-side only — no host or daslang change. The convenience GET/POST stay as-is; this uses dasHV's existing request(req) rail (HttpRequest.timeout). The new public http_get / http_post are grouped under "Raw HTTP" in utils/imgui2rst.das to satisfy the Uncategorized doc gate. Functional validation is the #118 rebase on CI (the windows-headless env where the wedge reproduces). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e0e41e2 to
e26a957
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
E1 from the integration-test sync investigation. On #118's
windows-latestrun,test_imgui_synth_ctrl_shortcutswedged for 159s and tripped:i.e. it ran all the way to the popen watchdog (
DEFAULT_TEST_TIMEOUT_SEC = 120) instead of failing fast.Mechanism: the live-API client used dasHV's convenience
GET/POST, which inherit libhv's default (effectively unbounded) response timeout. The host serves the live API on the GLFW main thread that also advances frames (see the header note inimgui_transport.das). So when a synth command wedges that thread, the host stops answering and stops rendering, and the client blocks on the POST with no timeout — the body can't make progress and the whole subprocess runs to the 120s watchdog. A mute 2-minute hang with no useful diagnostic.What
Add
http_get/http_posthelpers inimgui_transportbuilt on dasHV's existingrequest(req)rail (which exposesHttpRequest.timeout), with a hard per-request timeout (DEFAULT_REQUEST_TIMEOUT_SEC = 10s), and route every client call through them:live_api_transport'sPOST /command(every command + snapshot poll)wait_until_ready'sGET /statusget_text(→reload/reset/read_status)post_signal(POST /shutdown//reload//reset)Now a wedged host yields a
null/status==0reply in ~10s, so thewait_untilbudgets actually bound the failure and the diagnostic is legible instead of a silent 120s hang.Scope / non-goals
request(req)rail, so no dasHV add was needed; the convenienceGET/POSTstay as-is.test_docking_basiccrash (0xC0000409, deferred). Both become much easier to diagnose once the harness fails in seconds rather than minutes.Validation
windows-latestheadless is the env where the wedge reproduces. The local harness needs a Releasedaslang-livethis dev box doesn't currently have, so a local end-to-end smoke wasn't possible; the change is functionally equivalent to the old path plus a timeout (both go through libhvrequests::request).🤖 Generated with Claude Code