For unary and server-streaming RPCs the request body is collected before the deadline wrapper is applied (collect_body_limited runs ahead of the tokio::time::timeout call in connectrpc/src/service.rs), so a configured DeadlinePolicy bounds only handler execution, not the time spent receiving the request. A request that sends headers and then delivers its body very slowly holds the request future for as long as the connection stays open, regardless of policy. Client-streaming and bidi RPCs are not affected because the body is read inside the handler.
Proposed work: start the deadline clock before body collection (or wrap the body read in the same timeout), so that with_default_timeout / with_max bound the whole request. Worth doing together with the connection-level timeout work, since with the default no-op policy there is currently no time bound at all.
For unary and server-streaming RPCs the request body is collected before the deadline wrapper is applied (
collect_body_limitedruns ahead of thetokio::time::timeoutcall inconnectrpc/src/service.rs), so a configuredDeadlinePolicybounds only handler execution, not the time spent receiving the request. A request that sends headers and then delivers its body very slowly holds the request future for as long as the connection stays open, regardless of policy. Client-streaming and bidi RPCs are not affected because the body is read inside the handler.Proposed work: start the deadline clock before body collection (or wrap the body read in the same timeout), so that
with_default_timeout/with_maxbound the whole request. Worth doing together with the connection-level timeout work, since with the default no-op policy there is currently no time bound at all.