archetech / archon / 31834816549

95%

push

github

feat: Separate acknowledging DIDComm messages from retrieving them (#884)

* feat: Separate acknowledging DIDComm messages from retrieving them

receiveDidComm deleted messages from the mailbox as soon as it could
decrypt them, treating "I could decrypt it" as "I have it safely". It
persists nothing itself, so a message was retrieved, removed server-side,
and left to exist only in the caller's memory. A caller that crashed,
declined to store it, or simply printed and exited lost it permanently.

Two clients on the same DID could not both receive either, since whoever
polled first drained the mailbox.

Add an `ack` option (default true, so existing callers are unaffected) and
a separate ackDidComm(ids). Each unpacked result now carries its mailbox
id, so a caller can retrieve with ack: false, store the messages, and
acknowledge them afterwards. This matches DIDComm Pickup 3.0, where
messages-received is a client-driven ack sent once the client has stored
what it fetched.

Nothing accumulates as a result: the relay already enforces a message TTL
(ARCHON_DIDCOMM_MESSAGE_TTL_MS, 7 days by default) in both the memory and
redis stores, which remains the backstop for anything never acknowledged.

Applied across every surface that carries the receive/remove pair: JS
keymaster, client + types, CLI (--no-ack, ack-didcomm), MCP server, REST
router (POST /didcomm/ack), the pure-Python keymaster port and its CLI,
and the Python SDK.

mediateDidComm is deliberately left alone. Once a mediator has relayed an
envelope onward, deleting it is the correct behaviour, so it keeps the
current semantics rather than inheriting the flag.

Closes #883

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test: Add unit coverage for the DIDComm ack split

The first pass exercised the new behaviour through the e2e relay, the
client, MCP and the Python SDK, but not the Keymaster class directly.
Add unit tests in the existing mocked-gateway style:

- receiveDidCom... (continued)

3629 of 4089 branches covered (88.75%)

Branch coverage included in aggregate %.

33 of 34 new or added lines in 4 files covered. (97.06%)

8274 of 8557 relevant lines covered (96.69%)

689.6 hits per line