Halt does not propagate past a `yield*`-delegated sub-operation whose `finally` yields

[tarasvalstro]

Summary

When a task is halted while suspended, and the suspended point is inside a
yield*-delegated sub-operation whose finally performs asynchronous work
(any yield*), the coroutine does not stop after that finally completes — it
resumes normal execution past the halt, running subsequent statements and
even subsequent yield* operations. A synchronous finally behaves correctly.

Environment

• effection 4.0.3 (also reproduces on main / source tree)
• Reproduced on Node 22 and Deno

Minimal reproduction

import { run, sleep, suspend } from "effection";

function* halted() {
  try {
    yield* suspend();
  } finally {
    yield* sleep(0); // any async work in the finally
  }
}

let leaked = false;
const task = run(function* () {
  yield* halted(); // delegated sub-operation
  leaked = true;   // BUG: runs after the task was halted
});

await task.halt();
console.log("leaked:", leaked); // prints true; expected false

As a failing test in the style of test/scoped.test.ts:

it("does not run code after a halted operation whose finally yields", async () => {
  let leaked = false;

  function* halted() {
    try {
      yield* suspend();
    } finally {
      yield* sleep(0);
    }
  }

  let task = run(function* () {
    yield* halted();
    leaked = true; // must not run: this is after a halted operation
  });

  await task.halt();

  expect(leaked).toBe(false);
});

Observed behavior matrix

code after the halted delegated op	finally	result
bare statement	yield* sleep	runs (BUG)
bare statement	synchronous	does not run (OK)
inside try { } catch { }	yield* sleep	runs (BUG)
inside try { } finally { }	yield* sleep	runs (BUG)
statement + another yield* after	yield* sleep	both run — full resume (BUG)

The last row is the most concerning: the coroutine fully resurrects and keeps
yielding after the halt as if it had never been halted.

The existing test can suspend in yielded finally block does not catch this
because it has no normal code after the delegation; it only asserts finally
ordering and that the task reports halted (which task.halt() reports
regardless of whether the body continued).

Root cause

lib/coroutine.ts, step():

} else if (data.unwinding && !data.critical) {
  data.unwinding = false;
  return iterator.return
    ? iterator.return()
    : { done: true, value: undefined };
}
return iterator.next(resumeWith.value);

On halt, step() issues a single iterator.return() and clears unwinding.
When the finally reached by that return yields, the routine suspends; on
resume it falls through to iterator.next(...). For a same-frame finally this
correctly completes the return. But when the halted point is inside a
yield*-delegated child, resuming the child's finally with .next() lets the
child return and the parent's yield* deliver that value, so the parent
continues normally. V8 does not preserve the parent's abrupt-return intent
across the async-finally suspension when the generator is resumed with
.next().

Why the obvious fix is insufficient

Keeping unwinding set and re-issuing iterator.return() on resume regresses
async finally blocks that run code after a yield: re-issuing return() aborts
the remainder of the finally. With that change the suite fails 7 tests,
including:

• coroutine: uses 'return' for a single iteration when unwound
• run: can perform async operations in a finally block
• run: can suspend in yielded finally block

So a fix must let a finally complete its own post-yield code via .next(),
while still propagating the return/halt through yield* to the parent once the
delegated sub-operation finishes returning.

Suggested fix direction

Preserve the "returning" state across an async finally's resumption so that,
once a delegated sub-operation completes its return, the parent is returned
rather than resumed — without aborting the finally's own post-yield code. This
likely requires tracking unwind/return state per delegation frame (rather than a
single unwinding boolean cleared after the first return()), or managing
operation composition explicitly instead of relying on native yield*
return-propagation.

[taras]

Root-cause analysis

This is real, and it's the general form of #1185 — but unlike #1185 it cannot be fixed at the coroutine level. The reason is a property of native generator delegation, not an Effection quirk.

The fundamental conflict (pure JS, no Effection)

function* child()  { try { yield 'c-suspend'; } finally { console.log('  child f-enter'); yield 'c-fin'; console.log('  child f-exit'); } }
function* parent() { yield* child(); console.log('  PARENT-RESURRECTED (leaked)'); }

// C) parent.return() then .next()   (what the coroutine does today)
{ let it = parent(); it.next(); it.return('R'); it.next(); }
//   child f-enter
//   child f-exit                 <- finally cleanup completes  ✅
//   PARENT-RESURRECTED (leaked)  <- but the delegator resurrects ❌

// D) parent.return() then .return()  (the "keep unwinding sticky" fix)
{ let it = parent(); it.next(); it.return('R'); it.return('R2'); }
//   child f-enter
//   (no child f-exit)            <- finally cleanup is skipped  ❌
//   (no resurrection)            <- delegator stops             ✅

To let a delegated child's suspended async finally finish its cleanup, you must resume the chain with .next() — but that resurrects the delegating parent (the leak). To stop the parent resurrecting, you must resume with .return() — but that skips the child's finally post-yield cleanup.

There is no single resume verb on the top iterator that does both, because the resurrection happens synchronously inside the same .next() call that completes the child's finally (see case C). The child frame needs .next() and the parent frame needs .return() — different verbs at different depths of one yield* chain. The coroutine only holds the top iterator; it can't address frames independently.

Empirical confirmation

Making unwinding sticky in step() (re-issue .return() every resume) fixes all leak variations (delegated, two-level delegation, etc.) but breaks 3 existing tests — exactly the cleanup-completion contract:

• coroutine → "uses 'return' for a single iteration when unwound"
• ensure → "runs the given operation at the end of the task"
• all() → "rejects when one of the operations reject"

These break because .return() aborts the post-yield half of async finally/cleanup blocks. (Note: synchronous finally and inline async finally already work — the leak is specific to async finally in a delegated sub-operation.)

Why the #1185/#1186 re-arm can't be generalized to cover this

scoped/trap re-arm the unwind in their own finally (via trap.exit()). But the leaked statement runs in user code below that boundary, during the .next() resurrection — before the boundary's finally ever regains control. I verified scoped(halted) leaks for the same reason: the async finally completes via .next(), the body returns a value, trap.outcome gets set to Ok, and t.exit() therefore does not re-arm. The re-arm fires one frame too late.

This isn't a regression from the #1168 unify refactor either: the pre-#1168 Delimiter re-armed cancellation only at Effection operation boundaries, never around a plain yield* userGenerator(), so it would leak this same repro.

Conclusion

The literal repro — plain yield* gen() where gen has an async finally and there is code after the yield* — is not fixable with a localized coroutine patch. Fixing it requires Effection to stop relying on native yield* delegation and instead drive each delegated operation through an iterator it controls, so it can apply .next() to the child (to finish cleanup) and .return() to the parent (to stop resurrection) independently. That's a delegation-model change.

Practical options:

1. Boundary-level fix: make Effection's own boundaries (call/spawn/scoped/resource/run) drive their operation as a controllable sub-iterator so halt propagates through async finally for code that goes through them; document plain yield* as a limitation.
2. Delegation-model change: the full fix above (highest scope/risk).
3. Document the limitation: halt-sensitive operations with an async finally should be invoked through a delimited boundary, not plain yield*.