smokePackagedRenderer in scripts/verify-packaged-app.mjs reserves a CDP port, launches the packaged app with it, and polls http://127.0.0.1:<port>/json/list. When that poll times out, the error names neither the port it polled nor the deadline's cause:
Error: Packaged Maka renderer did not expose CDP within 30 seconds: fetch failed.
DevTools listening on ws://127.0.0.1:59034/devtools/browser/f8d99344-...
The app's own stderr carries a port; the verifier's message does not. So the one comparison that would classify the failure — are these the same port? — cannot be made from the log.
Observed: run 32108361079, package, on #3148. It failed in the upgrade-lifecycle step while the same binary had passed the identical smoke ~3 minutes earlier in the same job. A re-run of the identical tree passed, so the failure was environmental — but establishing that took a re-run rather than a read of the log.
Why the log is not enough. Three causes produce this same message, and only one is already distinguishable:
- the app failed to start — ruled out, since
child.exitCode !== null reports exited before its renderer was ready instead, and the captured stderr held no error
- the app is listening on a port the verifier is not polling
- the app is listening on the right port and simply had not served CDP within 30s
The second and third are indistinguishable today. I tried to separate them and could not: an occupied port makes Electron print no DevTools listening line at all (so the printed line argues against a mismatch), and the lifecycle step's reuse of one smokeDirectory across both app versions — a real difference from the standalone check that passed — reproduced 3/3 passes locally when I reused that Chromium profile.
Suspected cause of the flakiness itself: reserveTcpPort binds port 0, reads the number, then closes the socket before Electron binds it. Between those two points the port is free for anything else on the runner to take. Whether that is what happened here is exactly what the log cannot say.
Suggested fix, smallest first:
- Include the polled port and the elapsed time in the timeout message. One line, and it makes this class of failure classifiable on sight.
- Read the real port from
<user-data-dir>/DevToolsActivePort, which Chromium writes, instead of trusting the requested number. That removes the reserve-then-release race rather than only reporting it.
Scope note: this is diagnostics for the release verifier, not a product defect, and it is independent of any open PR.
smokePackagedRendererinscripts/verify-packaged-app.mjsreserves a CDP port, launches the packaged app with it, and pollshttp://127.0.0.1:<port>/json/list. When that poll times out, the error names neither the port it polled nor the deadline's cause:The app's own stderr carries a port; the verifier's message does not. So the one comparison that would classify the failure — are these the same port? — cannot be made from the log.
Observed: run 32108361079,
package, on #3148. It failed in the upgrade-lifecycle step while the same binary had passed the identical smoke ~3 minutes earlier in the same job. A re-run of the identical tree passed, so the failure was environmental — but establishing that took a re-run rather than a read of the log.Why the log is not enough. Three causes produce this same message, and only one is already distinguishable:
child.exitCode !== nullreportsexited before its renderer was readyinstead, and the captured stderr held no errorThe second and third are indistinguishable today. I tried to separate them and could not: an occupied port makes Electron print no
DevTools listeningline at all (so the printed line argues against a mismatch), and the lifecycle step's reuse of onesmokeDirectoryacross both app versions — a real difference from the standalone check that passed — reproduced 3/3 passes locally when I reused that Chromium profile.Suspected cause of the flakiness itself:
reserveTcpPortbinds port 0, reads the number, then closes the socket before Electron binds it. Between those two points the port is free for anything else on the runner to take. Whether that is what happened here is exactly what the log cannot say.Suggested fix, smallest first:
<user-data-dir>/DevToolsActivePort, which Chromium writes, instead of trusting the requested number. That removes the reserve-then-release race rather than only reporting it.Scope note: this is diagnostics for the release verifier, not a product defect, and it is independent of any open PR.