Skip to main content

encode_transport_stream_result_with_status_for

cratestack

Function encode_transport_stream_result_with_status_for 

Source 
pub async fn encode_transport_stream_result_with_status_for<TTransport, TValue, S>(
    transport: &TTransport,
    headers: &HeaderMap,
    capabilities: &RouteTransportCapabilities,
    success_status: StatusCode,
    result: Result<S, CratestackError>,
) -> Response<Body>
where
    TTransport: HttpTransport,
    TValue: Serialize + Send + 'static,
    S: Stream<Item = Result<TValue, CratestackError>> + Send + 'static,
Expand description

Genuinely incremental counterpart to encode_transport_sequence_result_with_status_for for @stream procedures (cratestack#283): result carries the still-unconsumed item Stream rather than an already-collected Vec. Err here means a preflight failure (authorization, before anything was produced) — the ordinary buffered error path applies, since nothing has streamed to the client yet. A failure during the stream is a different thing entirely and never reaches this function as an Err: it’s absorbed into the item stream itself as the tag-48900 sentinel (see super::stream_sequence).

Only application/cbor-seq gets the truly incremental path. Any other negotiated content type (plain JSON/CBOR array) falls back to draining the stream into a Vec first and reusing the existing buffered encoder — arrays can’t be flushed incrementally the same way, and docs/design/rpc-transport.md §3.3 only specifies incremental delivery for cbor-seq. This keeps a @stream procedure requested with a plain Accept behaving exactly like it did before this ticket.