Skip to content

Conversation

@FUDCo
Copy link
Contributor

@FUDCo FUDCo commented Jan 13, 2026

Implements message acknowledgment and retransmission.

  • Updates RemoteCommand type to include seq (sequence number) and ack (piggybacked ACK) fields
  • Per-peer sequence tracking that persists across reconnections
  • Implements timeout/retry logic with promise-based tracking

Closes #656


Note

Introduces reliable remote messaging with sequencing and acknowledgments, plus API and infrastructure updates.

  • Switches sendRemoteMessage to accept RemoteMessageBase (object) instead of string across kernel, browser, and node runtimes; updates RPC payloads accordingly
  • Adds handleAck and updateReceivedSeq methods and wires them through PlatformServices (browser/node) as fire-and-forget calls
  • Extends RemoteHandle to parse seq/ack on inbound messages, call ACK handlers, and send base messages without local stringify
  • Adds PeerConnectionState for per-peer state (seq tracking, pending queue) and revamps MessageQueue to store PendingMessage with capacity-based rejection
  • Updates network layer to assign seq, piggyback ACKs, track/retry with timeouts, and improve reconnection/flush behavior; adds timeout guard to libp2p.stop()
  • Updates Kernel/RemoteManager to forward RemoteMessageBase; removes auto-reply send on handler return
  • Broad test updates (unit/e2e) and config tweaks (longer hook timeout, cleanup helpers); marks one flaky reconnection test as TODO

Written by Cursor Bugbot for commit 2a0f438. This will update automatically on new commits. Configure here.

@FUDCo FUDCo requested a review from a team as a code owner January 13, 2026 06:55
FUDCo and others added 2 commits January 13, 2026 13:27
Implements message acknowledgment and retransmission:

- Update RemoteCommand type to include seq (sequence number) and ack (piggybacked ACK) fields
- Add per-peer sequence tracking that persists across reconnections
- Implement data structures with cumulative ACK support
- Implement transmission timeout with limited retries
- Reject pending promises when giving up on reconnection
- Fix deadlock in receiveMessage by using fire-and-forget for reply sends
- Fix PlatformServices to return reply instead of sending it
- Add handleAck and updateReceivedSeq to PlatformServices interface
- Implement delayed ACK mechanism (50ms timer) for standalone ACKs
- Add timeout to libp2p.stop() to prevent cleanup hangs
- Close channel streams explicitly on stop to unblock pending reads
- Fix e2e test cleanup with parallel stops and increased hook timeout
- Skip flaky "handles connection failure and recovery" test

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@FUDCo FUDCo force-pushed the chip/message-ack-retransmission branch from 74790e7 to 7697239 Compare January 14, 2026 18:01
FUDCo and others added 2 commits January 14, 2026 10:39
Restored validateMessageSize, checkConnectionLimit, and cleanupStalePeers
functions that were accidentally removed during message sequencing changes.
Also restored lastConnectionTime tracking and cleanup interval setup/teardown.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…scarding

The browser runtime's #handleRemoteMessage was always returning an empty
string, discarding the reply from the remoteDeliver RPC call. This broke
reply-based protocols like ocap URL redemption.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
FUDCo and others added 2 commits January 14, 2026 11:49
Previously getNextSeq() was called before attempting to add a message to
the queue, so rejected messages would still consume sequence numbers.
This caused gaps in sequence numbering, which led to incorrect sequence
numbers during retransmission since they were inferred from position.

Changed addPendingMessage to assign and return the sequence number
internally, only incrementing after successful enqueue.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
In the browser runtime, when the kernel worker calls sendRemoteMessage,
the offscreen document awaits sendWithAck which waits for an ACK. When
the ACK arrives via remoteDeliver, the kernel worker calls handleAck
back to the offscreen. If handleAck awaited, this creates a deadlock
because the offscreen's RPC message handler is blocked on the original
sendRemoteMessage request.

Making handleAck fire-and-forget breaks the deadlock while still
ensuring ACKs are processed correctly.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@FUDCo FUDCo force-pushed the chip/message-ack-retransmission branch from 12d0fcf to 2a0f438 Compare January 14, 2026 22:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remote comms: Message Acknowledgment and Retransmission

2 participants