Keep a preference usable when persistent storage fails
Keep a preference usable when persistent storage fails. A runnable teaching fixture with synthetic cases, a broken branch, and explicit untested cells.
A playable should not fail its whole startup because a non-essential preference cannot be saved. This fixture checks an explicit fallback for storage errors without claiming persistence succeeded.
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: storage fallback is the governing reference for the browser primitive. MDN documents localStorage as origin-scoped storage and lists situations in which access can raise a SecurityError. Availability should not be assumed solely because the API name exists. The fixture policy around that primitive is ours.
The failure the fixture isolates
The fixture supplies a storage-like adapter that either accepts a write or throws. The corrected branch returns saved or session-only accurately; the broken branch lets the exception escape. It does not touch the browser's actual storage, so the observed result is an adapter-handling regression.
The broken branch is retained so a producer can see the exact mistake, not only the repaired output.
| Case | Input | Expected (fixed) | Broken output |
|---|---|---|---|
| write accepted | `true` | `"saved"` | `"saved"` |
| write rejected | `false` | `"session-only"` | `{"threw":true,"message":"storage unavailable"}` |
| repeat rejected write | `false` | `"session-only"` | `{"threw":true,"message":"storage unavailable"}` |
All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.
What a pass does not prove
A pass shows that the application can continue with an honest non-persistent state. It does not prove privacy-mode behaviour, quota handling in every browser or survival across sessions. A fallback should preserve the current interaction while making no promise that the next launch will remember the preference.
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
Keep optional settings independent from core game initialisation. In the real host, test both reading and writing storage and handle each failure path. For a mute preference, retain the in-memory choice during the session even if persistence is unavailable, and avoid retry loops that repeatedly block or log the same exception.
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.
