Build History for pull/70

docs: update routeguide tutorial prose for Seq.writer API The client_streaming and bidirectional_streaming paragraphs still described the old option-based writer API (f (Some value) / f None). The code blocks were already correct; only the explanatory prose was stale. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

grpc-eio: pipeline request DATA concurrently with response HEADERS The gRPC over HTTP/2 protocol and RFC 9113 §5.1 place no ordering constraint between client DATA frames and server HEADERS. A conforming server may withhold response HEADERS until END_STREAM is received; a client that serialises await-HEADERS-then-send-DATA cannot interoperate with such servers. Change Rpc.handler from H2.Body.Writer.t -> H2.Body.Reader.t -> 'a to H2.Body.Writer.t -> H2.Body.Reader.t Eio.Promise.t -> 'a call invokes the handler immediately with write_body; the handler can begin sending the request body before response HEADERS arrive. read_body_p resolves once the server emits its HEADERS frame. bidirectional_streaming runs the two directions as concurrent Fiber.both fibers — the natural decomposition when send and receive are decoupled at the protocol level: send: f + grpc_send_streaming_client (no dependency on HEADERS) recv: await read_body_p; grpc_recv_streaming Adds lib/grpc-eio/test/test_concurrent_handler.ml: an integration test using an in-process server that withholds HEADERS until END_STREAM, verifying a clean unary round-trip. Fixes #64. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

grpc-eio: fix concurrent request body for grpcio/grpc-core interop Prior to this commit, Grpc_eio.Client.call called Promise.await on the HTTP/2 response before returning write_body to the handler. This caused a deadlock when connecting to grpcio (Python), grpc-core (C++), or any other gRPC server that withholds response HEADERS until it has received the complete client request stream. Root cause: get_response_and_bodies blocked at Promise.await response (client.ml:42 pre-fix), preventing the handler from ever calling write_body, while the server waited for END_STREAM before dispatching its handler — mutual deadlock. Fix: change Rpc.handler from H2.Body.Writer.t -> H2.Body.Reader.t -> 'a to H2.Body.Writer.t -> H2.Body.Reader.t Eio.Promise.t -> 'a The call function now invokes the handler immediately with write_body (before response headers arrive) and passes read_body_p, a promise that resolves once the server sends its HEADERS frame. Bidirectional streaming is restructured with two concurrent Eio.Fiber.both fibers: - Send side: starts immediately, writes the request body, then closes - Recv side: awaits read_body_p, then drives grpc_recv_streaming This is consistent with how flush_headers_immediately:true (already present) ensures the HEADERS frame is sent immediately, but the prior code still blocked on the response before writing any DATA frames. Verified against the gRPC over HTTP/2 protocol specification (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md) and RFC 9113 §5.1: a conforming server may defer response HEADERS until END_STREAM is received; the client must not assume otherwise. A new integration test (lib/grpc-eio/test/test_concurrent_handler.ml) exercises this scenario in-process: a mock server withholds HEADERS until the full request is received, and verifies the call completes without deadlock. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>