[rpb-ant]

Three small buffer-management fixes on the request/response path, plus a bench that isolates them from HTTP. Additive API (one new Envelope fn); no wire change. Reviewed with the repo's rust-code-reviewer and rust-api-ergonomics-reviewer agents; their Medium findings (keep decode* signatures concrete, changelog accuracy) are applied.

What and why

• encode_view_body / encode_view_body_with_min_segment write through a Vec<u8>, not a BytesMut. These size their own buffer and encode the view into it (the path every generated impl Encodable<M> for MView takes). bytes does not inline <BytesMut as BufMut>::put_slice, so every tag and varint byte written through a BytesMut is an out-of-line call; a pre-sized Vec<u8> + Bytes::from is zero-copy, allocation-free at len == capacity, and 3–4× faster. Owned-message paths (Encodable for M, PreEncoded, client request encoding) call buffa's encode_to_bytes, which buffa ≥ 0.9.3 already routes through a Vec (encode: encode_to_bytes writes through Vec<u8>, not BytesMut anthropics/buffa#437), so they're left alone — verified below. Upstream bytes fix: Inline BytesMut's specialized BufMut methods and add put_u8 fast paths tokio-rs/bytes#850.
• New Envelope::decode_bytes_with_limit(&mut Bytes, max) — decode_with_limit for a body already held as Bytes; the payload is split off by reference count (Buf::copy_to_bytes is zero-copy on Bytes) rather than the body first being copied into a BytesMut. The three places that did that copy just to de-frame — the gRPC unary and server-streaming handlers on the server, and the Connect client-streaming response scan on the client — use it: one allocation and one body-sized memcpy less per message. decode / decode_with_limit keep their &mut BytesMut signatures and now share a private body with the new function.
• gzip compress_inner no longer doubles its pre-sized output buffer before the first write; it grows only when spare capacity is exhausted (3 allocations / ~3× input bytes → 2 / ~1× per compressed response).
• benches/rpc/benches/encode_frame.rs: view_encode/* (view → Bytes via buffa's two entry points and encode_view_body) and deframe/* (decode_with_limit on a BytesMut copy vs decode_bytes_with_limit on the Bytes), over a 346 B, 4.4 KB and 271 KB log-record message and a 256 KB four-string blob.

Numbers

criterion medians, one pinned core (Xeon 8488C), main → this branch:

bench	main	this branch
view_encode/small_300B/connectrpc_encode_view_body	628 ns	166 ns
view_encode/logs_4KB/connectrpc_encode_view_body	4.56 µs	1.21 µs
view_encode/logs_256KB/connectrpc_encode_view_body	264 µs	75.4 µs
view_encode/blob_256KB/connectrpc_encode_view_body (memcpy-bound)	5.33 µs	5.59 µs
deframe/small_300B copy → in place	50 ns	25 ns
deframe/logs_4KB copy → in place	103 ns	25 ns
deframe/logs_256KB copy → in place	5.42 µs	25 ns
gzip, 256 KB text (allocs / bytes allocated, one-off count)	3 / 792 KB	2 / 265 KB

End-to-end (rpc_bench, loopback, ~70 µs floor): unary −1…−8 %, gRPC server-streaming −6 %, other arms within noise — these are per-message constant costs, visible as CPU more than latency.

Why the owned paths are not touched: on main with only the buffa dependency swapped (0.9.2 → 0.9.2 + anthropics/buffa#437), Encodable::encode goes 647 → 184 ns, 4.87 → 1.38 µs, 282 → 86 µs (= the Vec reference), while encode_view_body stays at 563 ns / 4.16 µs / 237 µs — the buffa bump fixes everything except the sites changed here.

Testing

cargo test --workspace (937 passed), cargo test -p connectrpc --no-default-features (514), cargo clippy --workspace --all-features --all-targets -- -D warnings, cargo fmt --check; conformance server and client suites pass. New unit test that decode_bytes_with_limit aliases its input, leaves incomplete input untouched, and rejects over-limit frames.

Follow-ups (not here)

• Client request framing without the copy (fused Vec when uncompressed, or header + payload as two body frames ≥ 16 KiB): saves one alloc + memcpy per request but makes HTTP/1.1 request bodies chunked; wants its own discussion.
• zstd output overhang: compress returns a Vec with cap = compress_bound(N); a tiny result pins an N-sized buffer until sent.