[atesgoral]

Summary

Add an opt-in maximum_receive_message_size: client option, backed by Protocol::GRPC::Body::Readable's maximum_size: option.

• Defaults to nil (unlimited).
• Applies to unary, server-streaming, client-streaming and bidirectional responses, including returned readable streams.
• Is forwarded by .open and inherited or explicitly overridden by .with.
• Limits both declared response payloads and incrementally expanded gzip/deflate output, excluding the five-byte frame prefix.
• Leaves outgoing request sizes unchanged.

Unlimited clients omit the new reader keyword, preserving compatibility with earlier protocol-grpc releases.

Companion dependency

This is a draft companion to protocol-grpc's receive-size option. A configured limit needs a released protocol-grpc version supporting maximum_size:; published 0.17.0 does not. This draft must not merge until that companion is released and the minimum dependency is updated accordingly. No speculative release version or fork dependency is committed here.

Validation

Local validation on Ruby 4.0.7:

• Full suite with the companion reader on the load path: 119 tests passed, 243 assertions.
• Existing suite against published protocol-grpc 0.17.0, without the companion overlay: 84 tests passed, 201 assertions.
• RuboCop on the client, new regression tests, guide and generated context: no offenses.
• API documentation coverage: all 29 public definitions documented.

The new HTTP/1 and HTTP/2 tests cover all four RPC patterns, exact and oversized responses, construction/inheritance and unrestricted request sizes. Compression integration tests cover unary gzip/deflate expansion; the final-status regression covers an in-limit unary response with real final non-OK trailers.

CI cannot exercise the configured limit with only the currently published reader; cross-repository release/dependency coordination is required.

Separate lifecycle follow-up

The existing bidirectional error-cleanup behavior is unchanged. A local HTTP/1 probe found that an exception before the caller closes its output can leave the request writer open and pool capacity held on both baseline and candidate code. This receive-size patch does not repair that separate lifecycle gap.