Skip to content

Encode messages before storing in send buffer#278

Draft
cbrewster wants to merge 1 commit intomainfrom
10-23-Encode_messages_before_storing_in_send_buffer
Draft

Encode messages before storing in send buffer#278
cbrewster wants to merge 1 commit intomainfrom
10-23-Encode_messages_before_storing_in_send_buffer

Conversation

@cbrewster
Copy link
Member

Why

I want to start enforcing max payload size before we attempt to send the messages over the wire.

Ideally we can confine these errors to be per-stream so one bad RPC call doesn't explode the entire client.

As a pre-req, we need to check for the max payload size before accepting messages into the send buffer, which means we need to encode them first to figure out the full payload size.

An additional benefit is we only ever encode messages once rather than re-encoding every time we resend messages from the send buffer. Granted, this is probably not a path we hit very often.

What changed

  • Encode messages before storing them in the send buffer
    • We keep around the id / seq number since we do need to have access to these for some tests and for keeping track of which messages have been acked by the peer and can be dropped from the send buffer

Versioning

  • Breaking protocol change
  • Breaking ts/js API change

@cbrewster cbrewster requested a review from a team as a code owner October 23, 2024 22:48
@cbrewster cbrewster requested review from jackyzha0 and removed request for a team October 23, 2024 22:48
@cbrewster
Copy link
Member Author

cbrewster commented Oct 23, 2024

Current dependencies on/for this PR:

This comment was autogenerated by Freephite.

@cbrewster cbrewster marked this pull request as draft October 23, 2024 22:51
@cbrewster cbrewster force-pushed the 10-23-Encode_messages_before_storing_in_send_buffer branch from e870c73 to 5310a52 Compare October 24, 2024 04:13
@cbrewster cbrewster force-pushed the 10-23-Encode_messages_before_storing_in_send_buffer branch from 5310a52 to 577c1d7 Compare October 24, 2024 04:15
@cbrewster cbrewster mentioned this pull request Oct 24, 2024
2 tasks
@cbrewster cbrewster marked this pull request as ready for review October 24, 2024 15:30
@lhchavez lhchavez requested a review from masad-frost October 24, 2024 17:07
@masad-frost masad-frost marked this pull request as draft February 19, 2026 17:05
@masad-frost masad-frost removed their request for review February 25, 2026 01:19
jackyzha0 added a commit that referenced this pull request Mar 8, 2026
## Why + What changed

spiritual successor of #278

- Moves message encoding (codec.toBuffer) before incrementing the
sequence number and pushing to the send buffer, so that if encoding
fails (e.g. unserializable values like `Symbol`), or JS cannot allocate
memory for the buffer, the session `seq` doesn't get out of sync
- Changes the send buffer type from OpaqueTransportMessage[] to
EncodedTransportMessage[] so buffered messages are already serialized
and don't need re-encoding on
reconnect
- Adds tests for unserializable values in procedure handlers (binary
codec throws, JSON codec silently drops)

## Versioning

- [x] Breaking protocol change
- [ ] Breaking ts/js API change

<!-- Kind reminder to add tests and updated documentation if needed -->
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.

2 participants