AI Stuck Bug — AI played a Planeswalker Ob Nixes, activated it's ability, then a pop up appeared saying failed to activ…

[matthewevans]

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

Thread: AI Stuck Bug
Discord thread id: 1529853535959912520
Discord message id: 1529853535959912520
Cards: none detected
Parser status: has_gaps
Extraction confidence: 0.90

Summary

AI played a Planeswalker Ob Nixes, activated it's ability, then a pop up appeared saying failed to activate Planeswalker ability after the ability alr

Reported text

AI played a Planeswalker Ob Nixes, activated it's ability, then a pop up appeared saying failed to activate Planeswalker ability after the ability already resolved and activated and now game is stuck, debug saying AI controller stuck attached game state and picture

Attachments

• Screenshot_20260723-070943.png
• game-state-turn-30-2026-07-23T14-09-35-214Z.zip

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

No card names were detected for this report.

---

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

[mike-theDude]

Triage analysis

Clarified summary

After an AI-controlled Ob Nixilis activates a planeswalker ability and that ability resolves, the client reports a second failed activation and the AI controller becomes stuck.

Investigation findings

The report includes both a screenshot and saved game state. The symptom is an AI action/state-machine failure after a completed planeswalker activation; no particular Oracle clause is identified strongly enough to attribute it to card data. No exact duplicate was found.

Acceptance criteria

• The AI submits each planeswalker activation once and advances after it resolves.
• A resolved activation is not retried against stale state.
• If an AI proposal becomes invalid, recovery returns priority or chooses another legal action without locking the game.
• The attached state replays without the failure popup.

Related issues

No exact duplicate found.

[mike-theDude]

Classifier analysis

Verdict: not_card_data
Matched clause: None (supported: not applicable)
Reasoning: The reported failure is duplicate/stale AI activation handling after resolution, not an asserted mismatch between an Oracle clause and its parsed AST.

---

Posted by bug-coverage-classifier skill.

[matthewevans]

Triage — Ob Nixilis is a red herring; the defect is an orphaned resolution frame

Investigated the attached capture (turn 30, 4-player, players 2 and 3 already eliminated).

The planeswalker is not the bug

Ob Nixilis of the Black Oath, object 398, controller 1 (AI), cast this turn, loyalty 3 → 1.
The AI activated [−2] (create a 5/5 Demon, lose 2 life), and it fully succeeded:
Demon token 456 exists on the battlefield, P1 life_lost_this_turn: 2,
objects[398].loyalty_activations_this_turn: 1, loyalty_abilities_activated_this_turn: {"1": 1}.

CR 606.3 enforcement is correct at both layers (verified at docs/MagicCompRules.txt:2715):
can_activate_loyalty_ability_impl (game/planeswalker.rs:97-172) gates per-permanent on
loyalty_activations_this_turn >= cap where cap = 1 + extra_loyalty_activations_this_turn, and
the AI's own enumerator honours it (candidates.rs:3603-3618 →
casting.rs:17228-17248). Empirically, legalActions in the capture contains only
PassPriority and CastSpell{104} — the Ob Nixilis abilities are correctly absent.

No change needed to Ob Nixilis, CR 606.3, or the loyalty path.

Symptom A — "failed to activate Planeswalker ability"

That exact string does not exist in the tree. The toast is assembled by showActionError
(client/src/game/dispatch.ts:275-281) as "{{action}} failed" with actionLabel returning the
generic "Action", plus the raw engine message — so the popup was almost certainly
"Action failed / Cannot activate loyalty ability"
(EngineError::ActionNotAllowed from game/planeswalker.rs:189-192). I could not confirm the
literal text: the Discord CDN attachment on this issue has an expired signature and 404s.

Since the AI's enumerator excludes a second activation, the rejection came from an
already-applied action being submitted again — matching the reporter's "after the ability
already resolved and activated". dispatch.ts:372-403 has a rehydrate-and-retry path that
re-invokes submit() after STATE_LOST, and AI-initiated failures route through the same
showActionError (dispatch.ts:614) — so an AI failure produces a user-facing toast for
something the human never did. That reporting behaviour is a defect in its own right.

Symptom B — the actual softlock

The capture violates a structural invariant the engine guarantees by construction:

resolving_stack_entry.kind.type == "TriggeredAbility"
resolving_trigger_firing        == null

begin_resolving_stack_entry (game/stack.rs:34-47) is the only production writer and carries
debug_assert_eq!(matches!(&entry.kind, TriggeredAbility{..}), firing.is_some());
take_stack_trigger_firing (:373-382) defaults legacy rows to TriggerFiring::UnknownLegacy,
so a triggered carrier always gets Some.

Why it is permanent. resolving_stack_entry_can_settle (game/engine.rs:4350-4362) requires
resolving_trigger_firing.is_some() == carrier.is_triggered() — here false == true → the
conjunction is false. That gate is the sole guard on settle_finished_resolving_stack_entry, the
only path to finish_resolving_stack_entry at a priority boundary. The self-heal sweeper is
disabled precisely by the condition it exists to repair. The four debug_assert! tripwires in
game/stack.rs are compiled out at opt-level='z', so it fails silently in release.

All other holds are clear (pending_replacement, resolution_stack,
pending_resolution_completion, pending_cast, deferred_triggers, pending_trigger_order,
post_replacement_drain_stack all null/empty), so nothing else is holding the frame open.

How the frame got there. Ob Nixilis [−2] → Demon token 456 enters → P0's Soul Warden
triggers on the opponent's token → Boon Reflection doubles the gain to 2
(players[0].life_gained_this_turn: 2) → P0's Voice of the Blessed triggers. That trigger is
the leaked carrier: id 458, source 15, LifeChanged { player_id: 0, amount: 2 }. Token is
object 456, frame is 458 — temporally adjacent, so causal rather than incidental.

Its PutCounter needed to pause on a CR 616.1 ordering choice (verified at
docs/MagicCompRules.txt:3173): P0 controls both Hardened Scales and Conclave Mentor, two
mandatory AddCounter replacements on one event. There is dedicated pause/resume plumbing for
this (crates/engine/tests/integration/loyalty_replacement_order_resume.rs). Instead the export
shows waiting_for = Priority { player: 1 } with an empty stack.

Why this capture can answer the question when others cannot

client_state_wire_value (game/derived_views.rs:418-434) unconditionally removes
resolving_trigger_firing and resolved_rules_journal from every client-bound state, so most
exports cannot evidence this at all. This capture has 6 resolved_rules_journal entries, so it
did not pass through that projection and the null is genuine. (Opponent hand names are also fully
visible, consistent with the raw single-player path.)

Not determined

• Which path broke the invariant. Three production paths null resolving_trigger_firing while
  leaving the carrier intact (derived_views.rs:428, visibility.rs:125,
  derived_views.rs:439-452). The decode-side compensation at game_state.rs:8071-8087 inserts
  LegacyDelayed when absent, but is gated on allow_unlabeled_v1_carriers — so a current-schema
  snapshot round-tripping through a stripping projection decodes with the invariant broken. A
  save→restore / attemptStateRehydrate() round-trip is the natural candidate and would also
  explain symptom A, but I could not confirm which projection the single-player persistence path uses.
• Which NULL path the AI took. get_ai_action_proposal (engine-wasm/src/lib.rs:1949-1995)
  returns JsValue::NULL when choose_action_with_session returns None or when
  contract.contains_action is false; the client logs neither
  (aiController.ts:376-384 sets failed = true with only a debugLog). Six of those trip
  MAX_TOTAL_FAILURES → notifyEngineLost("ai-controller-stuck:Priority") → stop(), matching
  the reporter's "AI controller stuck" and closed duplicates Ugin, Eye of Storms ultimate breaks game. — [[Ugin, Eye of Storms]] error is diagnostic: ai-controller-stuck:Priority #6415 / Diagnose: ai-controller-stuck — during a bot game the was stopped with Diagnose: ai-controller-stuck #5987.
  Note the AI does not read resolving_stack_entry at all (zero references in crates/phase-ai),
  and GameState's PartialEq does not compare it — so a leaked frame is invisible to search
  equality but is carried into every cloned search state.

Suggested fix direction

1. Make the parity break observable in release — the debug_assert!s are compiled out.
2. Fix the asymmetric redaction: a projection that strips resolving_trigger_firing must
   either strip the carrier too or preserve the pairing; and the decode compensation at
   game_state.rs:8071-8087 should not be gated on v1 schemas only.
3. Instrument the silent NULL path in aiController.ts:376-384 — reporting which branch the
   engine took is the single piece of information that would have closed Ai controller stuck — Just had a game get stuck in relaunch because Ai controller stuck. #6393 / Ai controller stuck — Just had a game get stuck in relaunch because Ai controller stuck. #6394 / Diagnose: ai-controller-stuck — during a bot game the was stopped with Diagnose: ai-controller-stuck #5987
   without a state capture.
4. Regression test (building-block level, not via Ob Nixilis): assert
   resolving_trigger_firing.is_some() == carrier.is_triggered() survives a
   serialize → redact → deserialize round-trip for a paused TriggeredAbility carrier.

Would falsify this: if the single-player persist/rehydrate path serializes raw state, the
mechanism in (2) is wrong — though the invariant break itself still stands, since it is read
directly from the data.