← back to v156 · avoid-caching-module-failures
conformance · v156
v156 · avoid-caching-module-failures — conformance probe
5 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
5
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
failed-fetch-is-retried |
A second import() of a module URL whose fetch failed (HTTP 404) issues a real second network request instead of rejecting from the module map cache. spec ↗ | script | … | |
retry-still-rejects-while-url-broken |
Both import() attempts of a still-broken URL reject with a TypeError; the change makes the retry reach the network, not succeed by magic. spec ↗ | script | … | |
parse-failure-still-cached |
A module served with HTTP 200 that fails to parse is NOT refetched by a second import(): only network and status failures became retryable, parse failures still produce a cached errored module script. spec ↗ | script | … | |
successful-module-still-cached |
A healthy module imported twice resolves both times from a single network fetch: successful module map entries remain cached as before. spec ↗ | script | … | |
recovery-through-unstable-network |
A module that failed on a flaky network is recoverable by a later import() once the network heals, without reloading the page. spec ↗ | manual | … |