feat: show whether a recipient is actually reading (#162) - #174
Merged
Merged
Conversation
Every `send` reported `sent <id> → <recipient>`, including the ones the recipient could never retrieve. In a session where several recipients were failing to read, the bus reported success 25 times while delivery was degraded, and no sender ever got a hint. `sent` has only ever meant QUEUED. The bus already knew enough to say more: pending inbox keys, and now a `lastRead` stamp written when an agent actually consumes its mailbox. So `send` warns when the evidence says nobody is picking the mail up — the recipient never registered under that name, or has unread stacking up with no consuming read in AGENTCOMM_STALE_READ_MS (6h). `agents` carries each agent's unread depth and how long ago it last read; `network` shows the same, plus a section for mail queued to names nobody ever registered, which a roster built from registrations alone cannot show at all. Counting is keys-only (one list, no bodies), and the read stamp rides commands agents run a handful of times a session.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #162. (Supersedes #170, auto-closed by GitHub when its base branch merged; same commit, rebased onto
main.)Every
sendreportedsent <id> → <recipient>, including the ones the recipient could never retrieve: 25 sends reported success in one session while delivery was degraded, and no sender ever got a hint.senthas only ever meant queued.What changed
src/bus.ts—lastReadon the agent record, stamped bymarkReadwhen an agent consumes its mailbox (inbox,ack). Only an existing registration is stamped: registrations are never purged, so a one-offinbox --as someonemust not leave a permanent ghost on the roster. PlusunreadCounts()/unread(name)— per-recipient depth from keys alone, one list, no bodies.src/cli.ts—sendwarns when the evidence says nobody is picking the mail up: the recipient never registered under that name, or has unread stacking up with no consuming read withinAGENTCOMM_STALE_READ_MS(6h). The warning rides--jsontoo.agentsgains unread depth and last-read age;networkshows the same, plus unread for nobody — mail queued to names nobody ever registered, which a roster built from registrations alone cannot show at all.Tests
test/bus.test.ts: unread counts (including unregistered mailboxes),lastReadstamped and preserved across heartbeats, and no registration conjured by a read.test/cli.e2e.test.ts: an unregistered recipient warns on the first send, a registered one only once mail stacks up unread, the warning stops after a real read, andnetwork --jsonlists the unclaimed mailbox.