Files
multica/server
Lambda 3fd4c9cf3d fix(onboarding): hand the kickoff to a queued successor, not to nobody (MUL-5827)
Review catch. Adoption happens inside a send's transaction, so a message the
member queues WHILE the kickoff's turn is still running finds nothing to adopt
and never gets another chance. Releasing the kickoff to NULL when that turn
died therefore left the already-sealed successor to execute with no onboarding
skill, no profile block, and no record that Mika had already greeted them —
the double introduction this design exists to prevent. Worse, a message sent
later could adopt the orphan instead, delivering the context to a turn that had
nothing to do with the opening.

ReleaseOnboardingKickoffFromTask now re-targets the session's next un-started
turn, falling back to NULL only when there is none. Three restrictions on the
target, each load-bearing:

  - status = 'queued' only. A dispatched/running successor has already built
    its prompt from its input batch, so joining it now would consume the
    kickoff without ever delivering it; it waits unowned for the next send.
  - chat_input_task_id = id selects roots that own their input batch. A retry
    child names its root, and the kickoff is already reachable through that
    root, so retries must not be re-targeted.
  - regenerate_quick_actions_for IS NULL skips background suggestion passes,
    which carry no user input.

Ordering matches the shared visible-head selector, so the kickoff lands on the
turn the member will actually see run next.

Covers both directions: A-owns/B-queued/A-fails hands off in the right order,
and an already-dispatched successor is skipped. The first test fails against
the previous NULL-only release.

Co-authored-by: multica-agent <github@multica.ai>
2026-08-07 17:25:22 +08:00
..