What happened?
Subject: message-child reports success for a message that is never delivered
DevSwarm 2.5.3, macOS (Darwin 27.0.0).
Not a size issue: the lost message was ~1900 characters, the successful resend ~2050.
Two separate problems. First, a returned record with an id and timestamp isn't evidence of delivery, and a caller can't distinguish accepted-then-lost from delivered. Second, there's no queryable queue state and no on-disk log behind ~/.devswarm/local-server/cli.sock, so I couldn't determine whether the loss happened on send, in the queue, or on read.
Why it matters. In a multi-child fan-out the highest-consequence messages are merge and sibling-pull instructions. A silently dropped sibling-pull leaves branches diverging with no signal until a later merge conflicts. We've added sequence numbers and ack-tracking on our side, but that only makes loss detectable after the fact.
Would help: a delivery receipt distinct from the send acknowledgement, a message-status query, or an inspectable log.
Steps to reproduce
During a parent/child fan-out, one of four hivecontrol workspace message-child calls never reached the child. The send returned a populated record — an id, createdAt: 2026-09-28T06:54:42.185Z, and the usual "Message sent." hint. The child later enumerated its inbox and reported receiving only the messages sent at 05:59:30 and 06:55:41. The 06:54:42 one was absent. Messages either side of it arrived, in order. A resend of identical content at 06:56:25 arrived normally.
Environment
No response
Relevant logs or screenshots
No response
What happened?
Subject: message-child reports success for a message that is never delivered
DevSwarm 2.5.3, macOS (Darwin 27.0.0).
Not a size issue: the lost message was ~1900 characters, the successful resend ~2050.
Two separate problems. First, a returned record with an id and timestamp isn't evidence of delivery, and a caller can't distinguish accepted-then-lost from delivered. Second, there's no queryable queue state and no on-disk log behind ~/.devswarm/local-server/cli.sock, so I couldn't determine whether the loss happened on send, in the queue, or on read.
Why it matters. In a multi-child fan-out the highest-consequence messages are merge and sibling-pull instructions. A silently dropped sibling-pull leaves branches diverging with no signal until a later merge conflicts. We've added sequence numbers and ack-tracking on our side, but that only makes loss detectable after the fact.
Would help: a delivery receipt distinct from the send acknowledgement, a message-status query, or an inspectable log.
Steps to reproduce
During a parent/child fan-out, one of four hivecontrol workspace message-child calls never reached the child. The send returned a populated record — an id, createdAt: 2026-09-28T06:54:42.185Z, and the usual "Message sent." hint. The child later enumerated its inbox and reported receiving only the messages sent at 05:59:30 and 06:55:41. The 06:54:42 one was absent. Messages either side of it arrived, in order. A resend of identical content at 06:56:25 arrived normally.
Environment
No response
Relevant logs or screenshots
No response