Two consumer tests assumed a send completes synchronously within the
handler turn: the continuation-drain test polled on handler-call count
then immediately asserted on adapter.sent, and the split-brain heal
test drained with bare zero-delay yields. With ledger calls hopping to
worker threads around each send, the reply can land microseconds after
those checks. Poll for the actual sends with a bounded 2s window —
same invariants, scheduling-robust.
Issue #47699 reported Slack /goal continuations being enqueued by
_post_turn_goal_continuation -> _enqueue_fifo but never drained until the
next real inbound message woke the session. On the current tree the
continuation lands in the adapter pending slot while the
_process_message_background frame is still live, so the in-band pending
drain (and the finally-block late-arrival drain) spawns the follow-up
turn automatically — the reported stall is not reproducible on main.
Pin the two halves of that contract so it can't silently regress:
1. a continuation placed in the FIFO during the handler frame is
consumed as a second turn without any new user message, and
2. the runner's goal hook enqueues under the same session key the
adapter drain resolves (key mismatch would orphan the event).
Refs #47699. Reported-by: joesu-angible
kshitijk4poor
Teknium