Game Crash — Game Crash on mobile, with error message unable to restore game state, attaching game state, don't know if…

[matthewevans]

Reported in Discord: https://discord.com/channels/1485498006781427802/1508820077091360878/1508820077091360878

Thread: Game Crash
Cards: none detected
Parser status: fully_parsed
Extraction confidence: 0.90

Summary

Game Crash on mobile, with error message unable to restore game state, attaching game state, don't know if it'll actually be useful

Oracle text (verified from client/public/card-data.json)

No card names were detected for this report.

---

_{report_id: discord:1508820077091360878:1508820077091360878:0 · discord: 1508820077091360878/1508820077091360878}

[matthewevans]

Classifier analysis

Verdict: not_card_data_attributable

Matched clause: (none)

Reasoning: This is a game crash / state restoration failure on mobile, not a card-specific parsing or effect-resolution bug. The error "unable to restore game state" points to a serialization, WASM memory, or persistence layer issue. No card data or Oracle text parsing is relevant here.

---

Posted by bug-coverage-classifier skill.

[mike-theDude]

Triage

Area: engine · Priority: p0-panic · Status: confirmed

Reported behavior: Game crashed on mobile with an "unable to restore game state" error; the reporter attached a serialized game state.

Parser/runtime assessment: No card is involved — this is not a card-data or Oracle-text issue. The failure is in the game-state serialization/restore path: a saved state could not be deserialized back into a valid runtime game. This is a persistence/serialization defect (or a schema-version mismatch between the stored state and the current engine model), owned by the engine's state (de)serialization layer rather than any effect handler. The attached state should be a directly reproducible fixture.

Next step: Attempt to load the attached game state locally and capture the deserialization error to pinpoint the failing field/variant.

[matthewevans]

Fresh Discord retrieval recovered the attached 2.6 MB raw save. It is at WaitingFor::MulliganDecision on turn 1 and predates many current GameState fields. Current restore code accepts raw snapshots through PersistedGameState and the versioned ResolutionStateWire migration path, rather than deserializing it as a current trusted envelope. The original failure therefore needs a current runtime import/restore verification; the save itself does not identify a new card or engine-resolution defect to implement.

[matthewevans]

Follow-up correction: the initial schema suspicion does not survive a complete field audit. stack_paid_facts is already #[serde(default)], and every other May-era missing root/Player/GameObject field in the attached raw gameState is either defaulted or transient/skipped. The saved state is quiescent at MulliganDecision (empty stack; no pending cast or suspended resolution carrier).

Current import code also unwraps the debug-export wrapper before restore. There is therefore no evidence-backed migration to add safely. The remaining required discriminator is a real current UI/WASM import of this exact ZIP and the literal restore error if it still fails. Keeping needs-runtime-verify rather than fabricating a schema fix.

[matthewevans]

Fresh reproduction (2026-08-13) using the latest Discord attachment through Home → Load Game State → From File:

• The ZIP is accepted and parsed; its inner gameState is a 3-player Commander state at WaitingFor::MulliganDecision with no enabled range-of-influence setting.
• The client briefly routes to the new /game/<id>?mode=ai&players=3 URL, then falls back to /setup instead of reaching the Mulligan prompt.
• This narrows the failure to the async GameProvider resume path after persistence/route handoff, not the debug-export envelope or file reader. The current fallback clears the imported save and then attempts a fresh game, so it hides the underlying restore exception; next investigation is to surface that exact error and add a regression around the real imported attachment.

[matthewevans]

Root cause confirmed from the browser console: the saved state contains the legacy serialized Effect::Untap variant, while current deserialization accepts only SetTapState. PR #7383 migrates the complete legacy tap family only at the persisted effect payload boundary, preserving current card-data strictness and unrelated Untap enums. It includes a persistence round-trip regression.