Repository navigation
Flake: go-exit-code.test.ts first launch hits the 30 s proxy-init deadline while Delve builds the fixture under load (pre-push, Windows) #889
Description
Seen once, in the pre-push hook on Windows 11 (2026-10-09, main at e44f1fe + a docs-only commit; Delve at ~/go/bin/dlv.exe), while the box was also running other work. The retry passed.
FAIL |integration| tests/adapters/go/integration/go-exit-code.test.ts
> Go exit code from Delve's console status line (issue #753) > reports a non-zero exit code in debug mode
AssertionError: {"success":false,"state":"error","message":"Debug proxy initialization did not complete within 30s.
Connected to the debug adapter, but the \"launch\" request never received a response. The adapter process is running (PID 28820). ..."
× reports a non-zero exit code in debug mode 33287ms
✓ reports exit code 0 for a clean run in debug mode 14374ms
✓ reports the exit code under noDebug 9367ms
What the proxy log shows (proxy-9fb8d925-….log, timestamps UTC):
- 20:51:22.17 Delve spawned; connected after ~2.4 s of
ECONNREFUSEDretries (Delve still starting). - 20:51:24.58
initializeanswered in 3 ms. Noinitializedevent within 2 s (Delve sends it afterlaunch), so the launch-first fallback ran. - 20:51:26.59
launchsent (mode: debug,program: examples/go/exit_code,args: ["7"]). 2 ms later one stdoutoutputevent of 75 chars, then nothing for 25.5 s. - 20:51:52.15 the 30 s proxy-init deadline fired;
disconnecttimed out after 1 s;taskkilldid not end PID 28820, SIGKILL did.
Delve answers launch only after it has built the debug binary (go build -gcflags all=-N -l into a temp __debug_bin). This was the first case in the file, so the first build of the fixture in this hook run, on a loaded box; the next case launched the same fixture in 14 s. The 30 s deadline the proxy applies to launch therefore includes a cold Go compile and link, which under load can exceed it.
Proposals, cheapest first:
- In the Go integration suites, warm the build cache in
beforeAll(go build -gcflags all=-N -l -o NUL ./...in the fixture dir, output discarded) so the first launch does not pay for the compile. Same shape as the Flutter e2e's up-front build (feat(dart): Flutter on an Android emulator, measured end to end (#790, M3) #883). - The Go adapter could build ahead of the launch itself (the cpp adapter compiles a source launch before CodeLLDB sees it), which would also make the error on a build failure a diagnostic instead of a 30 s silence.
- Or treat Delve's build phase as progress: the first stdout
outputafterlaunchcould extend the init deadline once, the way readiness already distinguishes "no adapter response" from "adapter busy".
Not the #866 flake (that was the cleanup's rmSync EBUSY in the same file, fixed in #873).
Activity
debugmcpdev commentedon Oct 10, 2026
Hit again 2026-10-10 in the pre-push hook of a four-branch push (box loaded: two dev-proxy backends and a js-debug session from the #871 dogfood were running):
go-exit-code.test.ts › reports a non-zero exit code in debug modefailed at 33.3 s withinitProgress: {transportConnected: true, adapterPid: 2732, pendingCommand: "launch"}— the 30 s proxy-init deadline while Delve builds the fixture. Every other integration file passed (20/20) and all 355 unit files; the retry of the same push went through. Second occurrence in two days; the beforeAll warm-build proposal above would remove it.debugmcpdev commentedon Oct 10, 2026
From reading the code (not reproduced): the 30 s is
DEFAULT_PROXY_INITIALIZATION_TIMEOUT_MS = 30000insrc/proxy/proxy-manager.ts:212, armed at :426-436 and never overridden (src/factories/proxy-manager-factory.ts:28passes no options). Only the message is stage-aware:ErrorMessages.proxyInitTimeout(timeout, progress)reads theinitProgressthe worker'sdap_handshake_stagestatuses update; the #492 fix (initializeResponseOptional) is a separate worker-side race and does not extend the deadline.And the Delve build is inside that deadline: a
.gofile infersmode: 'debug'(packages/adapter-go/src/go-debug-adapter.ts:308-320), the Go policy setssendLaunchBeforeConfig: true(adapter-policy-go.ts:267), so the worker sendslaunch(:802) anddlv dapcompiles the program before answering it; the parent'sinitializedonly fires onadapter_configured_and_launched(proxy-manager.ts:1422-1442), after launch and configurationDone.So on a cold cache under pre-push load the first launch pays the whole compile against the fixed 30 s. Options: a per-policy init-timeout extension for adapters whose launch compiles (Go, and the C/C++/COBOL source launches), or a proxy-init deadline that restarts at each handshake stage instead of one budget for all of them.
debugmcpdev commentedon Oct 12, 2026
Second occurrence, 2026-10-12 (Windows pre-push hook on refactor/904-stop-anchor, unit project 360 files green, 20 other integration suites green):
go-exit-code.test.ts > reports a non-zero exit code in debug modefailed withDebug proxy initialization did not complete within 30s … the "launch" request never received a response … adapterPid 3276, pendingCommand: launch. Warming Delve's build by running the suite alone first (pnpm exec vitest run --project integration tests/adapters/go/integration/go-exit-code.test.ts, 3/3 in 43 s) and re-pushing passed (21 integration suites green). Same shape as the first report: a cold fixture build under hook load eating the fixed 30 s proxy-init window.debugmcpdev commentedon Oct 12, 2026
Another data point (2026-10-12, PR #915's first push): the pre-push hook's integration run hit the 30 s proxy-init deadline on
reports a non-zero exit code in debug mode(go-exit-code.test.ts, first Delve launch,"launch" request never received a response) while the unit project had just run; warming the suite alone (pnpm exec vitest run --project integration tests/adapters/go/integration/go-exit-code.test.ts, 3/3 in well under the deadline) and re-pushing passed. Same shape as the two earlier entries: load-sensitive first build, not the test.fix(proxy): spawn debug adapters detached on POSIX only; on win32 the…
debugmcpdev commentedon Oct 12, 2026
Fixed in #931, and the cause is not the one this issue names.
It was not the cold build. The adapter manager spawned every adapter with
detached: true, which on Windows isDETACHED_PROCESS— the child gets no console. Delve pays for that at every process it creates. Measured idle on this box:dlv versiontakes 0.1 s with an inherited or hidden console (CREATE_NO_WINDOW, whichwindowsHidesets) and 2–3 s underDETACHED_PROCESSorCREATE_NEW_CONSOLE(isolated per creation flag with Python'screationflags);go,node,python,java,rubyand CodeLLDB are unaffected. Under a detacheddlv dap, Delve's own log shows the warmgo build(0.2 s in a shell) taking 6 s and the debuggee start 4 s — a 1.16 s launch became 8–13 s idle, and all four sightings' proxy logs have that shape:launch, theBuilding …output event 2 ms later, then silence until the kill. Under pre-push load it crossed 30 s.The build was never silent: a Delve build failure answers
launchwithsuccess: falseandBuild Error: …on stderr; only a slow build can hit the deadline. Andlaunchsits under two fixed 30 s limits, the proxy-init deadline and the worker'sMinimalDapClientrequest timeout, so proposal 3 (extend the parent deadline on the first output) would have bought ~4 s.Proposal 1 was tried and dropped: a
beforeAllwarm build in Delve's exact shape (same flags, the file argument, the same cwd; the server chain inherits the runner'sGOCACHE) saved ~2 s per run and left the stall in place. The cold build is 3–9 s with a throwaway cache, 0.2 s warm.After the fix: the suite alone 48 s → 15 s, each debug-mode case 5.7 s,
launch→ response 1.17 s.debugmcpdev commentedon Oct 27, 2026
Recurred 2026-10-27 in the local pre-push hook on Windows 11 (branch for #1023, no
src/change, tree = main at 7e95a32):reports a non-zero exit code in debug modefailed with "Debug proxy initialization did not complete within 30s … the "launch" request never received a response. The adapter process is running", the same shape as this issue. Run alone right afterwards, the file passes 3/3 in 17 s (the first launch 6.4 s). The hook's integration run was the only load on the box; the #1006 pytest-preset case failed in the same run.debugmcpdev commentedon Nov 12, 2026
Recurred 2026-11-12 in the local pre-push hook on Windows 11 (branch of #1149, which changes nothing on the Go launch path):
reports a non-zero exit code in debug modefailed at 33.3 s with "Debug proxy initialization did not complete within 30s … the "launch" request never received a response", the adapter's last output beingBuilding …\examples\go\exit_code\main.go. The next two cases of the same file passed in 6.3 s and 3.8 s. Run alone right afterwards the file passed 3 of 3 (first launch 6.9 s), and the same push went through on the second try. The hook's integration run was the only load on the box.Same shape as the 2026-10-27 entry: after #931 the first Delve launch under the hook's load still occasionally exceeds the fixed 30 s proxy-init window.