Game crashes with attached game state (July 16 report)

[matthewevans]

Summary

A Discord report contains an attached game state for a game crash but no additional text diagnosis.

Expected behavior

Loading or resolving the captured state should not crash the game.

Oracle text\n\nNot applicable: this is a crash report with an attached game state.

[matthewevans]

Triage: the primary defect is already fixed — these are pre-fix captures

Investigated both attached states (#6926 turn-24, #6927 turn-32). They share one signature.

These are not the "unpayable tax" scenario the title suggests. Player 3 could pay in both:
6 and 4 untapped lands respectively against a {2} generic tax, and pay_unless_cost →
pay_effect_mana_cost → pay_non_cast_mana_cost auto-taps before the affordability check
(game/casting.rs:15568).

The real shape is goad + tax:

	turn-24	turn-32
Sole taxed attacker	317 Barret, Avalanche Leader	312 Rhox Faithmender
goaded_by	[0]	[0]

Walking every /goad/i path in both files: the only goaded permanent is exactly the only taxed
permanent. That is the defining shape of the class.

Pre-fix mechanism. The decline branch filtered taxed attackers out of the declaration; with a
single taxed attacker the result was empty, and the CR 508.1d requirement loop then rejected it
because the goaded creature still registered an unsatisfied "attacks if able" requirement. So
decline was rejected, both candidates were dropped by SimulationFilter, and legalActions came
back empty.

That is precisely what CR 508.1d forbids (verified at docs/MagicCompRules.txt:2269):

"If a creature can't attack unless a player pays a cost, that player is not required to pay
that cost, even if attacking with that creature would increase the number of requirements
being obeyed."

Two fixes landed; neither regressed — the second superseded the first:

1. cc9ca7be4e (fix(engine): allow declining combat tax for required attackers #6069, 2026-07-16) — added a declined_taxed_attackers exemption.
2. a38b18a3d3 (feat(engine): engine-owned DeclareAttackers legality with CR 508.1d requirement solver and AI completion #6164, 2026-07-18) — replaced it with a general CR 508.1d requirement solver;
   max_no_payment (game/combat.rs:1136, 3967, 3974) now computes the maximum requirement count
   attainable without paying any tax, so declaring zero attackers is legal at HEAD when the
   only forced attacker is taxed.

Turn-24 predates #6069 by ~11h. Turn-32 is ~5h after merge, but deploy + client-build lag makes a
pre-fix client near-certain.

Residual defect worth fixing independently

CR 508.1i is not implemented — no mana-ability window at the tax prompt.
ai_support/mod.rs:2133-2139:

fn mana_action_player(state: &GameState) -> Option<PlayerId> {
    match &state.waiting_for {
        WaitingFor::Priority { player }
        | WaitingFor::ManaPayment { player, .. }
        | WaitingFor::UnlessPayment { player, .. } => Some(*player),
        _ => None,
    }
}

CombatTaxPayment is absent. Compare UnlessPayment — the sibling CR 118.12 prompt — which has
dedicated handle_unless_payment_tap_land_for_mana / ..._untap_land_for_mana handlers
(game/engine.rs:7093-7110).

CR 508.1i (docs/MagicCompRules.txt:2280) grants an explicit mana-ability window before CR 508.1j
payment. Without it the player cannot choose which sources pay — material for pain lands
(turn-24 held Brushland), filter lands, and CR 106.6 spend-restricted sources; and any tax
payable only via a mana ability the auto-tapper declines to use is reported as unpayable. This is
the most plausible surviving generator of the "I thought I had the mana" reports in #4893/#5223.

This is a parameterization of an existing window, not a new mechanism: ~40-70 lines across
ai_support/mod.rs (one match arm), game/engine.rs (2-3 dispatch arms delegating to existing
engine_payment_choices helpers), and ai_support/candidates.rs.

Correction on an earlier line of analysis

I initially flagged a second residual — a TriggeredAbility carrier in resolving_stack_entry
with resolving_trigger_firing == null, which would make resolving_stack_entry_can_settle
(game/engine.rs:4350-4362) return false permanently. That is not supported by these two
captures. client_state_wire_value (game/derived_views.rs:418-434) unconditionally does
root.remove("resolving_trigger_firing") on every client-bound state, so the field can never
appear in an exported capture. Both of these exports also have resolved_rules_journal empty —
the same function removes that key — confirming they are wire-projected and the parity question is
unmeasurable from them.

Relationship to the cluster

Same class as #4345 / #4554 / #5230, but not the same games: those three are auto-filed
stuck-decision reports with stuckPlayers == [PlayerId(0)], whereas these captures are player-3
states. Merging the class is right; treating their diagnostics as describing these captures is not.

Suggested next step

Add an integration test in crates/engine/tests/integration/ that gzips these captures into
crates/engine/tests/fixtures/ (existing pattern: flate2::read::GzDecoder + include_bytes!,
see cr733_resolved_commands_p0.rs:13-31; .gameState deserializes as PersistedGameState) and
asserts legal_actions_full yields >= 1 action for a CombatTaxPayment prompt owner. That runs
under Tilt's test-engine with no manual cargo run and permanently guards the class. If the
captures fail to deserialize at HEAD, that is itself the answer to "can this still reproduce".