fleet/fleetd
3
0
Fork 0
Code Issues 78 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Features: fleet_ack does not destroy held peer mail, and heldDurable is derived 

Two corrections to the "A lead can read its own held peer mail" entry.

1. It said fleet_ack "would have destroyed the message before anyone read
   it". Measured false: fleet_ack calls MessageService.ackReply, which goes
   to the worker reply inbox, never to the coordination channel. It removes
   nothing and still reports "acknowledged <msgId>" (fleetd #437). The old
   sentence made a no-op sound like a data-loss risk, which is the opposite
   of the real defect.

2. heldDurable was a hardcoded true when this entry was written. Since
   fleetd #440 it is derived from the queue durability and the ack mode, so
   it can report false. Noted that one boolean over two inputs cannot say
   which of the two changed.
Dai Ha
2026-09-10 16:43:16 +07:00
parent bdaef4000c
commit 9b0a77b0ba
1 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
11-Features.md
+7 -3
@@ -2334,13 +2334,17 @@ so, because no route exists for reading another daemon's mail.
**On.** Nothing to configure beyond the `coordinator:` block that lead-to-lead messaging already
needs. Pass your own `selfId` — `fleet_list` reports it as `coordinator.selfId` — as `fleet_poll`'s
`coordId`. `fleet_list` also now reports `heldCount` and `heldDurable` beside `held[]`.
`coordId`. `fleet_list` also now reports `heldCount` and `heldDurable` beside `held[]`. `heldDurable` is
**derived** from the queue's declared durability and the consume ack mode, not written as a
constant, so it can actually report `false` if either changes (fleetd #440). It is one boolean
over two inputs, so a `false` does not say which of the two moved.
**Why.** A lead could see *that* it had peer mail but not read it. `fleet_list`'s `held[]` carries
only an 80-character preview, on purpose, so a constantly-called roster scan never dumps a
coordination body. `fleet_poll{target}` drained the wrong store — a worker's reply inbox, not the
coordinator mailbox — and returned an empty list with no error. The only other route, `fleet_ack`,
would have destroyed the message before anyone read it. So the full body was reachable in principle
coordinator mailbox — and returned an empty list with no error. The only other route, `fleet_ack`, looked
destructive but is not: it never touches the coordination channel at all, and reports
`acknowledged <msgId>` anyway (fleetd #437). So the full body was reachable in principle
and unreachable in practice, and the busiest leads were the ones most affected: delivery into a
lead's pane is status-gated, so a lead that never goes idle never drains its own mailbox.