Non-fatal engine panic: resolution abandonment cannot clear a buried ability continuation: Unexpected…

[UlisesTR15]

What happened
briefly describe what you were doing

Diagnostic

Build: v0.78.0 (4de7224)
Diagnostic tag: ai-getAction-panic
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36

Panic (engine recovered):
panicked at crates/engine/src/game/stack.rs:78:10: resolution abandonment cannot clear a buried ability continuation: UnexpectedTop { expected: AbilityContinuation, actual: PostReplacement }

[Makeinu1]

Current-main revalidation / design note

Revalidated on current main:

d570baa4f10bebaec312184f3a2829d27e112591

The original diagnostic's exact lifecycle seam is still present.

Current call chain

crates/engine/src/game/elimination.rs

A departing player can cause source-bound resolution abandonment through:

abandon_source_bound_resolution_prompt
  -> finish_abandoned_source_bound_resolution_carrier
  -> stack::abandon_active_resolution_carrier

crates/engine/src/game/stack.rs::abandon_active_resolution_carrier still performs:

state
    .clear_active_ability_continuation()
    .expect("resolution abandonment cannot clear a buried ability continuation");

The continuation consumer remains top-only: ResolutionStack::take_active_ability_continuation returns UnexpectedTop when another valid frame is above it.

That is the same failure vocabulary reported in this Issue:

UnexpectedTop {
    expected: AbilityContinuation,
    actual: PostReplacement,
}

What has improved since the report

Post-replacement live dispatch is now substantially stronger.

Current ResolutionStack code gives a live PostReplacement dispatch a stable PostReplacementFrameId, and finish_post_replacement_dispatch / related helpers address that exact frame by identity even when nested frame insertion changes its position.

That closes a class of live-dispatch adjacency bugs.

However, source-bound abandonment does not use that ownership authority. It still asks the stack top to be the AbilityContinuation.

So the current asymmetry is:

• live post-replacement dispatch: identity-addressed;
• source-bound family abandonment: top-position-addressed.

#9302 does not change this. #9302 adds stack_entry_node_reach for effect target/referent reach and explicitly has no production caller in that PR; it is not ResolutionFrame ownership.

Root cause

Frame creation/resume has several strong ownership tools:

• captured ChildStackDepth;
• insert_parent_at_child_boundary;
• typed frame IDs;
• identity-addressed PostReplacement dispatch;
• atomic frame-transition validation.

But lifecycle teardown does not retain an equivalent source-bound resolving-family handle.

A legitimate nested family may therefore have a shape such as:

AbilityContinuation(A)
  -> PostReplacement(C)
  -> nested typed child(s)

A buried continuation is not automatically corruption. It is legitimate when the parent/child relation is established by a frame identity, typed pair, or captured child boundary.

The bug is that abandonment infers ownership from "top" even though current stack APIs already support legitimate buried parents.

Preferred fix direction

Make source-bound abandonment owner-aware rather than adding another depth special case.

A resolving family should carry an exact ownership handle (stable frame id, captured family boundary, or equivalent typed authority) covering:

• its AbilityContinuation;
• its PostReplacement resident/drain;
• typed children spawned by that family;
• family-scoped relatch / deferred-entry state.

Then abandonment should:

1. validate that exact family relationship;
2. retire only frames owned by that family;
3. preserve unrelated sibling/outer frames;
4. clear only family-scoped relatch/deferred state;
5. reach a coherent Priority/GameOver state;
6. return/propagate a typed failure if the claimed family relation is absent, rather than partially clearing and then panicking.

Do not replace this with an unrestricted "search down the stack for AbilityContinuation". A buried frame is only safe to remove when ownership is proven.

Regression coverage needed

At minimum:

1. Exact reported shape

   • AbilityContinuation + PostReplacement;
   • source-bound departure/abandonment;
   • no panic;
   • expected final semantic/lifecycle result.

2. Deeper legitimate nesting

   • AbilityContinuation
   • PostReplacement
   • a second typed child (e.g. ChangeZone or direct choice);
   • test both normal resume and abandonment.

3. Isolation

   • unrelated resolution frames survive;
   • no broad stack clearing.

4. Terminal proof

   • expected stack survivors / empty owned family;
   • no stale relatch / deferred-entry event;
   • final effect/trigger/lifecycle receipt is correct, not merely "no panic".

5. Save/restore

   • serialize a paused family;
   • restore it;
   • ownership still identifies the same family or is deterministically remapped;
   • malformed owner references fail validation before execution.

Scope

This comment does not claim a new runtime card reproduction on the current head; this is current-main source proof of the original ownership defect and a design/acceptance update.

Related but separate:

• Engine crash: paused child operation must retain its continuation as an immediate parent #7950/Engine crash: paused child operation must retain its continuation as an immediate parent: P… #7987/Engine crash: paused child operation must retain its continuation as an immediate parent: P… #7787/Engine crash: paused child operation must retain its continuation as an immediate parent: P… #7823: direct-child/immediate-parent panic family;
• Engine crash: repeat-for drain may consume only the active repeat-for frame: UnexpectedTop … #7828: RepeatFor top-only sibling;
• Engine crash: start_next_turn requires an empty stack, no pending resolution carrier, and a… #8358/Engine crash: start_next_turn requires an empty stack, no pending resolution carrier, and a… #8215: terminal pending-carrier/turn-start liveness;
• feat(engine): report which objects and players each stack-entry node acts on #9302: effect reach, not frame ownership;
• [P2-A1-R5a] Stage resolution-time composite payments atomically #9263: payment lane, not part of this Issue.

The Issue can remain the canonical upstream owner for this abandonment defect.