Rust: bound JSON-RPC frames and transport queues while preserving cancellation

まず rust/src/jsonrpc.rs を読み、その後、サイズ超過および停止したフレーム、キューの圧迫、キャンセルについて、列挙されたインメモリまたはループバックトランスポートのテストを構築します。完了の条件は、決定論的なテストによって、フレームとキューに上限があること、明示的なエラーまたはバックプレッシャーがあること、キャンセルが速やかに行われること、正常にシャットダウンすること、および通常のトランスポートテストに合格することが示されることです。

Package: Rust Copilot SDK, current main at the time of investigation.

Summary

The Rust JSON-RPC transport accepts peer-provided frame lengths without a configured maximum, has no deadline for completing a partial frame, and uses unbounded channels for outbound frames and inbound request dispatch. A stalled or excessively large peer frame can therefore retain transport work indefinitely or cause allocation and queue growth outside a documented resource envelope.

Add deterministic transport tests and bounded framing and queue behavior while preserving cancellation-safe shutdown.

Current behavior

In rust/src/jsonrpc.rs:

• The writer uses an unbounded queue.
• Inbound request dispatch uses an unbounded channel.
• The parser allocates the message body directly from the peer-provided Content-Length.
• There is no maximum accepted frame size.
• There is no deadline for a peer that sends a header or body only partially.
• Frames are flushed individually. That may affect throughput, but flush batching is intentionally outside this issue.

These are confirmed implementation properties. The severity and production reachability should be determined by the transport tests rather than assumed.

Reproduction and tests

Add in-memory or loopback transport tests for:

1. A header declaring an oversized Content-Length.
2. A valid header followed by a body that never completes.
3. A body delivered slowly enough to exceed the read deadline.
4. A blocked writer while callers enqueue enough messages to reach queue capacity.
5. A peer flooding inbound requests faster than the application consumes them.
6. Cancellation and shutdown while reads, writes, and queue admission are blocked.

Tests should assert bounded allocation, deterministic error propagation, and prompt cancellation rather than depending on process memory exhaustion.

Expected behavior

• The transport rejects frames larger than a documented configurable or fixed maximum before allocating the declared body.
• Header and body reads cannot remain partially complete indefinitely.
• Outbound and inbound transport queues have documented bounds.
• Reaching a queue limit produces explicit backpressure or an explicit transport error rather than silent loss.
• Cancellation unblocks pending reads, writes, and queue admission.
• Transport shutdown completes without leaking worker tasks or dropping the final error state.
• Errors contain enough context to distinguish oversized, timed-out, closed, and backpressured transports.

Proposed scope

Limit this issue to:

• JSON-RPC header and frame-size limits.
• Partial-frame read deadlines.
• The Rust transport's writer queue.
• The Rust transport's inbound request-dispatch queue.
• Cancellation-safe error and shutdown behavior for those limits.

The exact defaults should be chosen from observed protocol payload sizes and compatibility tests.

Acceptance criteria

• Each reproduction has a deterministic automated test.
• Oversized frames are rejected before allocating the declared payload size.
• A stalled partial frame fails within the documented deadline.
• Queue capacity is enforced without silently dropping messages.
• Cancellation completes promptly while blocked on read, write, or admission.
• Normal request, response, notification, and shutdown tests continue to pass.
• Public configuration or error-contract changes are documented for Rust consumers.

Non-goals

• Session-router or application-level queue limits.
• HTTP request-body streaming limits outside the JSON-RPC transport.
• Frame compression.
• Batching or removing per-frame flushes.
• A general retry policy.
• Changes to other language SDK transports in the same issue.

Related work and non-overlap

• #1273 covers cooperative disconnect and shutdown behavior. This issue concerns frame and transport resource limits, while requiring those limits not to regress cancellation safety.