Problem
st2 message send accepts a message addressed to an identity that no longer exists. The message is written durably to that identity's inbox and stays there. Nothing bounces and nothing warns, so from the sender's side an undeliverable message is indistinguishable from a delivered one.
The failure is silent on both ends: the sender believes the work was handed over, and no live agent ever sees it.
Two receipts, found by a routine sweep rather than by anyone noticing
A task assignment, unread for 15 days. Silber.cos sent "Assigned: PTY restartable environment/config parity" to silber.pty-claude, a retired identity. The live owner is Silber.pty and never received it. The item had been assigned by the principal, so it was believed to be in flight for two weeks.
/…/catalog/silber.pty-claude/inbox/1785164088201-kt8x0w.md
A blocker, unread for 13 days. droppy.root reported that it could not satisfy its recovery contract and asked for an exact artifact. It addressed Silber.st2, which is dead; the live owner is hetz.st2. droppy.root then sat idle for roughly 200 hours waiting for an answer that could not arrive.
/…/catalog/agents/Silber/st2/resources/inbox/1785359885162-fxp25f.md
Both sends returned success.
Desired behaviour
Fail closed, or warn explicitly, at send time when the recipient is retired or nonexistent. Normal delivery to live identities must be unaffected.
Either shape solves the reported failure:
- refuse the send with a non-zero exit and a message naming the recipient, or
- accept it but emit an explicit warning that the recipient is not live, so the sender can re-route.
The important property is that the sender learns at send time, because that is the only moment when re-routing is cheap. A message discovered 15 days later has already cost what it was going to cost.
Notes
Problem
st2 message sendaccepts a message addressed to an identity that no longer exists. The message is written durably to that identity's inbox and stays there. Nothing bounces and nothing warns, so from the sender's side an undeliverable message is indistinguishable from a delivered one.The failure is silent on both ends: the sender believes the work was handed over, and no live agent ever sees it.
Two receipts, found by a routine sweep rather than by anyone noticing
A task assignment, unread for 15 days.
Silber.cossent "Assigned: PTY restartable environment/config parity" tosilber.pty-claude, a retired identity. The live owner isSilber.ptyand never received it. The item had been assigned by the principal, so it was believed to be in flight for two weeks.A blocker, unread for 13 days.
droppy.rootreported that it could not satisfy its recovery contract and asked for an exact artifact. It addressedSilber.st2, which is dead; the live owner ishetz.st2.droppy.rootthen sat idle for roughly 200 hours waiting for an answer that could not arrive.Both sends returned success.
Desired behaviour
Fail closed, or warn explicitly, at send time when the recipient is retired or nonexistent. Normal delivery to live identities must be unaffected.
Either shape solves the reported failure:
The important property is that the sender learns at send time, because that is the only moment when re-routing is cheap. A message discovered 15 days later has already cost what it was going to cost.
Notes
hetz.st2verified the second case read-only and confirmed the classification: accepted durable messages can become stranded with no refusal or warning.