Module bidi 

Available on crate feature server only.

Bidirectional-streaming: the prologue + responder split that straddles the run→upgrade seam.

Bidi is the one shape that can’t run entirely in Handler::run: read-while- write needs the response head already flushed, which only happens once run returns and Handler::upgrade is called. But the response’s initial metadata (and the content-type) must be committed in run, before the flush — and that decision may depend on reading the first request message (the conformance suite, for instance, carries the response-header definition in request 1). So bidi is two functions joined by an object, never a suspended future:

1. The prologue — the service trait’s bidi method. It runs to completion in run, holding a GrpcServerConn: it may read request messages (via GrpcServerConn::requests) to decide response headers, sets that initial metadata straight through to the Conn, and returns a BidiResponder. Returning Err(Status) rejects before the flush (trailers-only, no upgrade).
2. The responder — BidiResponder::respond, a fresh future built and driven in upgrade over a Channel. It owns the read-while-write loop. Trailing metadata is written through the channel (Channel::response_trailers_mut, seeded with whatever the prologue set) and emitted with grpc-status when it returns Ok(()) or Err(Status).

What actually crosses the seam is a BidiUpgrade in the Conn’s state: a type-erased BidiDriver (the boxed responder plus the codec fn-pointers, encodings, and prologue-set trailers it needs). The user’s loop future is not suspended across the seam — it’s created fresh in upgrade — so it never has to be moved while holding borrows into the channel. The request body’s receive state is retained from Conn onto Upgrade by trillium-http, so the responder’s Channel continues reading at the next frame after whatever the prologue consumed.

Traits

BidiResponder

The user-driven half of a bidirectional-streaming RPC: the read-while-write loop, created by the service method (the prologue) and run after the response head is flushed.

Functions

drive_bidi_upgrade

Drive a bidi RPC to completion over its upgraded transport: build the Channel, run the responder loop, and write the terminating grpc-status trailers. Generated Handler::upgrade delegates here. A no-op if the upgrade wasn’t ours (shouldn’t happen given has_bidi_upgrade gates it).

has_bidi_upgrade

Whether this upgrade was marked for bidi by the run-phase dispatch. Generated Handler::has_upgrade delegates here.