Treat a resolved HTTP error as a failed asset request

A loading screen can announce ready after receiving an error page if it treats a resolved fetch promise as success. This fixture checks the response status explicitly.

This article is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: http status is the governing reference for the browser primitive. MDN's Using Fetch guide states that fetch can fulfil with a Response even when the server returns an error status such as 404. Applications must inspect the response status rather than relying only on promise rejection. The fixture policy around that primitive is ours.

The failure the fixture isolates

The fixture creates actual Response objects for supplied status codes. The corrected branch uses their ok property; the broken branch assumes every received response represents a ready asset. No remote request is made, so transport, CORS and cache behaviour remain outside the test.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

The test establishes status handling for a response object. A successful status still does not prove that a downloaded file is the expected asset, can be decoded or matches its manifest. A production loader needs the next acceptance stage as well, particularly when an HTML error page can arrive with an unexpected success status.

Untested cells in this article: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

Separate request, status acceptance, decoding and readiness in the loader. Give failures a useful fallback and prevent the game loop from starting before essential assets are usable. Exercise the real deployment with deliberate missing files and a known error response before claiming a successful loading path.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.