grpc_timeout
Versions marked “overview” do not contain this page. Selecting one opens that version’s documentation overview.
On this page
Honours the grpc-timeout request header as a real deadline.
Configuration Notes
gRPC clients express a per-call deadline in grpc-timeout. Without this filter Praxis forwards the header untouched and applies only its static cluster timeouts, so a client that asked for 100ms can wait on a 30-second upstream read, and each retry restarts the clock.
The filter clamps the requested deadline to max_timeout_ms, holds it as an absolute instant for the life of the request, shrinks every upstream attempt’s connect and read budget to what is left, and rewrites grpc-timeout upstream with the remaining time. A call that is already past its deadline is answered DEADLINE_EXCEEDED without contacting the upstream at all.
Non-gRPC requests pass through untouched, so the filter is safe on a listener carrying mixed traffic.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
default_timeout_ms | integer | no | Deadline applied when a request carries no grpc-timeout header. Omit to leave header-less gRPC calls unbounded. |
headroom_ms | integer | no | Budget withheld from the upstream so the proxy can answer DEADLINE_EXCEEDED before the client’s own timer fires. |
max_timeout_ms | integer | yes | Ceiling applied to any client-supplied deadline. |
on_invalid | reject | ignore | no | What to do with a malformed grpc-timeout value. |
propagate | bool | no | Whether to rewrite grpc-timeout on the upstream request. |
Example
filter: grpc_timeout
max_timeout_ms: 30000 # ceiling, whatever the client asks for
default_timeout_ms: 10000 # optional: applied when the header is absent
headroom_ms: 50 # optional: budget kept back for the proxy
propagate: true # optional: rewrite grpc-timeout upstream
on_invalid: reject # optional: reject | ignore