Inbox: same pending message canceled + re-inserted after an error turn (429) - duplicate agent/inbox/spliced inserts

[skyloader2474]

Context

While auditing plugin-delivered steering messages in session logs (we run a duplicate-alert scanner over agent/inbox/spliced events), we observed an event-level duplication pattern that looks unintentional. Sharing in case it is known/desired behavior; two questions at the end.

Observation

A message inserted into the next-turn pending list during a turn that later ends with an LLM error (429 quota) gets canceled and immediately re-inserted at the same position when the next turn starts — producing two agent/inbox/spliced insert events for the same message id (161 ms apart, no net state change).

Timeline (UTC+8, 2026-10-01, session log excerpt; message ids abbreviated):

time	event	data (abridged)
04:01:17.229	agent/inbox/spliced	insert b286-…77229 @ next-turn[1]
04:01:17.387	turn/end	reason=error (429 Allocated quota exceeded)
04:01:17.390	agent/inbox/spliced	remove next-turn[1], removedCount=1, outcome:"canceled"
04:01:17.390	agent/inbox/spliced	insert b286-…77229 @ next-turn[1] (same id, same position)
04:01:37.373	agent/inbox/spliced	claim (remove, no outcome)
04:01:37.405	user/message	the message surfaces exactly once

So the model only sees the message once (claim → enter happens exactly once); the duplication lives at the event-stream level, which matters for consumers that replay or audit agent/inbox/spliced (alert-redelivery scanners, projections, log-validation tooling).

Source anchors (shipped tree)

• dsh-agent-loop ReactLoopInbox.claim() removes the full next-step batch (mutate("next-step", 0, len, [], false)) — claiming does drain; this is not a "queue never drains" report.
• mutate() only sets outcome:"canceled" on the public splice() path (discardRemoved=true); claims carry no outcome.
• dsh-agent tracks droppedUnrun when outcome === "canceled" — so there appears to be a re-queue path for canceled-but-unrun input, which would explain the remove+reinsert pair above.

Related prior reports on inbox splice stream oddities (different faces, same area): #3632 (orphan spliced splits vs session readability), #4274 (splice sequence conflicts on recovery), #4952 (queued follow-ups never admitted after turn end).

Questions

1. Is the cancel+reinsert pair at an error-turn boundary the intended recovery semantic (e.g. re-queue of dropped-unrun input)? If so, could it emit a distinguishable outcome (e.g. outcome:"requeued") so event-stream consumers do not count it as two deliveries?
2. Separately: pending next-turn messages can stay resident across several turns in our logs (4 turns / ~33 s in the sample above) before being claimed. Is there an intended upper bound or cleanup semantic for pending residency?

Happy to provide the full session excerpt if useful.

[argszero]

Answering both from the shipped tree, because the pair is not a recovery semantic — the loop never puts cancelled input back.

Where outcome: "canceled" comes from. ReactLoopInbox.mutate() sets that outcome only on a public mutation that actually removes something (discardRemoved && actualDeleteCount > 0), and that same branch emits agent/inbox/discarded. Claiming goes through the private path with discardRemoved = false, so claims are pure deletions carrying no outcome — exactly the difference your log shows: the cancellation event is a removal by the cancel path, not by a claim. The producers of that outcome are the public mutation API: clear() (which Agent.cancel() calls when keepInbox is false, next-step before next-turn) or a direct remove/splice by a consumer.

Nothing in core re-inserts a discarded message. All three listeners on agent/inbox/discarded are one-way: goal-round-driver marks its own queued attempt cancelled, user-questions releases a queued reply slot, and subagent's continuation-activation wakes its observer. None writes to the inbox. And droppedUnrun — the fold of "a cancellation took this input before any turn opened over it" — is read in exactly one place, subagent/src/lifecycle.ts, to classify a child's ending (aborted vs completed). It is a classification fact, not a requeue mechanism, so your reading of it as "a re-queue path for cancelled-but-unrun input" is the one thing I would correct here. Since there is no such path, there is also no requeued outcome to emit: the vocabulary has no such state because the behaviour has none.

That leaves the producer. The only way one MessageId can appear twice is a second delivery — and it is possible precisely because the cancellation removed it first, since duplicate ids are rejected only while pending (mutate() throws on a duplicate across both lists). One detail worth checking in your excerpt: Agent.send() reclassifies a waking input into next-turn when the phase is already aborted ("waking input cannot join an aborted activity, so it starts the next turn"), so a steer issued around an aborted turn lands in next-turn rather than next-step — that accounts for the target, not for the duplication.

For the scanner, the rule that holds today: agent/inbox/inserted is a per-delivery notification, not a per-message one. Key on message.id and treat discarded/claimed as the end of one pending residency. Comparing the source object of the two inserted payloads settles attribution immediately — a redelivery by the same producer carries an identical source, whereas anything the harness itself re-queued would carry a core source kind, which per the above does not exist today.

On residency (2): there is no upper bound, by design. claim('next-turn', turn) removes at most one queued turn per boundary and drains the entire next-step batch, so a queued turn waits exactly as long as the current turn runs — including steps, retries and long tool calls — and 33 seconds over 4 turns is a slow turn, not a leak. The only cleanup is Agent.cancel(), which clears both lists unless called with keepInbox: true. A time bound on pending residency would be a new policy rather than a missing cleanup; if you think it is warranted, that is worth raising as its own proposal.

[skyloader2474]

Thanks for the detailed explanation and source pointers. This clarifies that the canceled event is a removal, not a claim, and that core does not automatically reinsert discarded messages. That distinction is helpful for our local workflow investigation. Thank you for maintaining the project.