The FedWiki walkthrough fails on networks whose DNS drops loopback answers #236
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#236
Reference in New Issue
Block a user
What a contributor runs into
The test stack names the FedWiki farm under
localtest.me, a public domain whose names all resolve to127.0.0.1and::1. Some resolvers refuse to pass on a public name that points at the loopback address: home routers with DNS-rebind protection, some office resolvers and some VPNs. Without a network the name does not resolve at all.On such a network the app's call to the farm fails with
lookup admin.localtest.me: no such host.TestFedWikiSitesWalkthroughthen waits 30 seconds and fails in phase 1 with "row for walk-....sites.localhost never reached the expected state". Nothing in the failure names DNS, and the same commit passes on a network whose resolver answers.The walkthroughs' reachability guard (
skipUnlessIntegrationEndpointReachable) has the same blind spot. When its request to the farm fails on the lookup, it skips with "add "fedwiki" to COMPOSE_PROFILES", although the farm is composed.The farm cannot move to
*.localhostlike the stack's other names. FedWiki's sign-in shares one session cookie across the farm's sites, and browsers do not scope a cookie to.localhost, so sign-in on one site would not reach another.Why it costs
The suite's result depends on the network it runs on. A contributor on a filtering network gets a timeout or a misleading skip, with nothing pointing at the cause.
Where
test/e2e/operator-walkthroughs/helpers_test.go, test/bootstrap-stack.sh, test/AGENTS.md
Done when
*.localhost,*.localtest.me) resolves only to loopback addresses. When the check fails, the guard fails the test instead of skipping it, naming the host, what the lookup returned, and the hosts-file lines that fix it. An endpoint hosted elsewhere still passes the check.bootstrap-stack.shruns the same check on the farm's host whenever thefedwikiprofile is on, and prints the same fix.localtest.me, which resolvers break it, and gives the hosts-file lines.Fixed in
dbd3a890. The reachability guard looks the endpoint's host up before it sends the request and fails the test with the host, the reason and the /etc/hosts lines.bootstrap-stack.shprints the same fix when the fedwiki profile is on, and test/AGENTS.md has a section, "Names that must resolve to this machine".Reopening: the walkthrough guard never runs its name check, for the farm or for the forum.
skipUnlessIntegrationEndpointReachablereads the endpoint from the integration's settings page, from the field named for the key.fedwiki-farm-api-urlanddiscourse-base-urlare deployment-only keys, and the settings page renders a deployment-only key as static text, "Set fedwiki-farm-api-url in the environment.", with no field holding the URL. The guard finds nohttpvalue and returns early, treating the endpoint as unconfigured, so neither the resolution check added here nor the reachability skip runs.On a network whose resolver drops loopback answers for
localtest.me,make testagain fails inTestFedWikiSitesWalkthroughwith "row ... never reached the expected state; last ... Pending", and the console's log showslookup admin.localtest.me: no such hoston every farm call. The suite that closed this issue ran on a network that resolved the name, so it never exercised the check.The fix: the guard reads the endpoint from
test/.env(MC_FEDWIKI_FARM_API_URL,MC_DISCOURSE_BASE_URL), the file the walkthrough already loads and the console's environment comes from, and a test pins the mapping from key to variable so the guard cannot silently stop reading it again. The bootstrap warning and thetest/AGENTS.mdsection stand as they are.Fixed in
e1bb2959. The guard reads the endpoint fromtest/.env, under the variable the console reads for the key, and no longer visits the settings page.TestEndpointEnvVarpins the mapping from key to variable forfedwiki-farm-api-urlanddiscourse-base-url.