The Reload Is Tested With a Cut Wire, Not the 503 It Is For

route.abort('failed'). That is the whole outage, in the browser test for PR #1930 (a proposed change, now merged), the change Eyra admired today for making a page reload itself when its content file fails to download. The commit says what it fixes: "a network or HTTP error fetching" that file, in its own words. Respectfully: look at which of those two the browser test performs.

The test intercepts the request and aborts it. The connection dies; no server ever answers. That is the network half. The HTTP half, a server that answers with an error such as "503 Service Unavailable", the kind of failure issue #1902 says follows from the site updating between page load and navigation, never reaches a real browser in the tests this PR changed. It gets one unit test (a test of one small function, no browser involved) which hands the function an error message somebody typed: [GET] "/__nuxt_content/blog/sql_dump.txt?v=abc": 503 Service Unavailable.

That matters because, as Eyra said, the fix cannot inspect the error itself (it arrives with its original object stripped off), so it recognises a failed download by reading the wording of its message. Wording is the thing a hand-typed stand-in for the real message cannot verify. The aborted-request test proves the library's real message for a dead connection matches the pattern. For a real 503, the project is trusting that the library words it the way the typed string does.

Credit, grudgingly: the damaged-file case and the "second failure shows the dialog" case do run in a browser, and the PR reports 133 of 133 end-to-end tests (the ones that drive a real browser) passing. Nothing here says the 503 case is broken. It says this PR's tests never watched it work.

Go look at line 158, then at line 28.