Repository navigation
fix(chromium): reach CDP on ports Node's fetch refuses - #1937
Open
pcbeingused333 wants to merge 1 commit into
Open
pcbeingused333 wants to merge 1 commit into
pcbeingused333 wants to merge 1 commit into
Conversation
undici rejects the Fetch bad-port list before dialing, so a readiness probe of electronPort 6000 or 10080 failed at once and boot retried until the deadline. Repeat that GET with node:http, which can dial it.
This branch has not been deployed
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.
Fixes #1935
Cause:
fetchJsoninpackages/tool-server/src/chromium-server/cdp-session.tsprobes CDP with undicifetch. undici rejects the Fetch spec's bad-port list (6000, 10080, and the rest) before opening a socket.electronPortaccepts 1024–65535, andwaitForCdpReadytreats every probe failure as transient, so boot retries for the full 30s, kills the app, and reports that the connection failed. The same probe is why an app already listening on one of those ports is never discovered throughARGENT_CHROMIUM_PORTS.Fix: When undici fails with
bad porton a port at or above 1024, repeat that one GET withnode:http, which does not apply the bad-port block. A listener is then reached on the first probe, so boot returns instead of waiting out the deadline, and discovery sees the app. Ports below 1024 stay refused, so a probe of port 1 still fails before any socket. Connection errors, timeouts, non-2xx responses, and non-JSON bodies keep the same failure classification.Test:
packages/tool-server/test/chromium-discovery.test.tsstarts a CDP stub on a blocked port (10080, or the next free port in that list) and expectsdiscoverChromiumDevicesto return it. That case fails on main and passes with this change.Reproduction: a CDP listener on
127.0.0.1:10080answering/json/versionand/json/list. On main, discovery of that port returns nothing, andboot-devicewithelectronPort: 10080waits out the readiness timeout withCHROMIUM_ELECTRON_CDP_TIMEOUT, the cause chain ending inbad port. After this change the probe reads the listener.This change was prepared with AI assistance (Claude).