Fix Windows E2E test failures: bind native PHP site proxy to 127.0.0.1#4067
Open
gavande1 wants to merge 1 commit into
Open
Fix Windows E2E test failures: bind native PHP site proxy to 127.0.0.1#4067gavande1 wants to merge 1 commit into
gavande1 wants to merge 1 commit into
Conversation
On Windows, Node resolves 'localhost' to ::1 and binds the site proxy IPv6-only. Any client that reaches the IPv4 loopback — and CI Windows agents whose ::1 loopback is unusable — get ECONNREFUSED, so the site page never loads (every 'open a site' E2E test fails with a blank page). 127.0.0.1 is always available and clients loading http://localhost fall back to it. Also point the internal admin-credentials and readiness requests at 127.0.0.1 so they match the new bind address.
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
1 participant
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.
Related issues
How AI was used in this PR
AI analyzed the Buildkite logs from the first post-hang-fix Windows runs (builds #18670/#18671), correlated the 24 identical
ERR_CONNECTION_REFUSEDtest failures with the proxy'slisten( port, 'localhost' )call, and proposed the reproduction script that confirmed the IPv6-only bind on a Windows VM. The fix and commit were reviewed and tested by a human on that VM.Proposed Changes
After #4041 stopped the 3-hour hang, Windows E2E runs finished but still failed 24 tests, all the same way:
page.goto( http://localhost:<port> )getsERR_CONNECTION_REFUSED, so every "open a site" assertion sees a blank page.The cause is in the native PHP runtime's HTTP proxy (
apps/cli/php-server-child.ts): it listens with hostname'localhost', which Node resolves to::1on Windows and binds IPv6-only. Reproduced on a Windows VM: a server bound this way accepts connections on::1but refuses127.0.0.1. On the CI Windows agents, Chromium resolveslocalhostto127.0.0.1, so every navigation to a running site is refused — deterministically, which is why all 24 failures also failed their retry. (Linux E2E dodged the same class of problem with a--host-resolver-rules=MAP localhost 127.0.0.1browser flag; Windows has no such flag.)The fix binds the proxy explicitly to
127.0.0.1, which is always reachable — clients resolvinglocalhostto::1fall back to IPv4. The internal admin-credentials and readiness requests now also target127.0.0.1so they check the address the proxy actually listens on, instead of passing via::1while browsers get refused.Testing Instructions
E2E Tests on windows-x64job (enabled on the base branch) should no longer shownet::ERR_CONNECTION_REFUSEDfailures; the ~24 "open a site" tests should pass and the run should complete in roughly the pre-regression time (~25-30 min) without retry inflation.npm run e2e -- site-creation— previously failed at the site-page assertion, passes with this change.127.0.0.1is valid loopback on all supported platforms.Pre-merge Checklist