Repository navigation
investigate(delivery): extend request-ID deduplication safely to ordinary local and SSH sends #182
Description
Reddit feedback
A reader proposed a message UUID plus target identity and a durable receiver-side idempotency record before acknowledgement. Source: https://www.reddit.com/r/ClaudeCode/comments/1wotkse/i_built_sessionpeer_to_hand_off_messages_between/
Current v1.0.0 boundary
Paired-device Direct/Relay already has a request UUID and receiver journal that deduplicates native submission across routes. It does not prove agent consumption. Ordinary local/SSH send has no equivalent durable idempotency contract. --request-id is not a universal retry key.
Scope
- Determine whether and where a receiver-side journal can be placed for local and source-streamed SSH delivery without requiring a remote session-peer install or writing into another agent's state.
- Specify identity binding (host, agent, exact session generation, message hash), retention, conflict handling, crash recovery, permissions, and privacy.
- If feasible, implement at-most-once native submission for a repeated ID/body and reject the same ID with different content or target. Do not acknowledge before durable commit or promise exactly-once consumption.
- If infeasible for a transport, document its honest
unknown / do not retry automaticallycontract instead of adding a misleading flag. - Cover lost response, concurrent repeat, restart, SSH interruption, and cross-host ID collision in tests.
Coordinate with the generation-pinning issue; deduplication must not let a new session inherit an old request ID.
Activity
abruption commentedon Oct 1, 2026
Thanks, @fujiezee. I agree with the receiver-dedup and unknown-outcome feedback in #181, and accept it as a design and acceptance-criteria follow-up for this long-term investigation.
The correlation ID should identify the original request during reconciliation, including a human-approved resend. That is a proposed dedup contract, not implemented idempotency:
--request-idis not currently a universal retry key. Paired-device journaling provides useful precedent, but does not prove consumption or establish durable receiver dedup for ordinary local/SSH delivery.The proposed contract should bind the ID to the exact destination and receiver generation, with a stored payload hash. Repeating the same ID for the same request must reconcile the stored outcome—including
unknown—without reinjection. Conflicting payloads or destination/generation bindings must be refused. Decisions after an unknown outcome, record expiry, or a receiver-generation change need explicit rules; uncertainty must not silently authorize another submission.Acceptance coverage should include duplicate request delivery, not only duplicate ACKs, plus concurrent duplicates, restart recovery, lost responses, retention boundaries, and receiver-generation changes. Retention limits must be visible to retry eligibility; an expired/missing record must not silently be treated as proof that the original request was never submitted. The intended guarantee is at-most-once native submission within the defined dedup scope, not exactly-once consumption by the target session.
This records the design follow-up coordinated with #181; it does not change the milestone or imply implementation approval.