Entrypoint forwarding timeout override in Traefik Mesh changes upstream request deadline

Question

Clarify how request lifecycle propagation is handled in Traefik Mesh when a client disconnects or a deadline expires, given that timeout behavior is governed by the underlying Traefik Proxy entrypoint and transport configuration.

The documented configuration transition occurs when operators override default forwarding timeouts at the mesh entrypoint level, which changes how long proxies wait for upstream responses before returning errors. SMI specifications do not natively express client cancellation or deadline propagation, so behavior relies on Traefik Proxy-level settings whose interaction with mesh routing is not fully documented. A compatibility boundary exists between SMI TrafficSplit policies and Traefik-native timeout settings, and the precedence that determines the effective deadline is not explicitly specified. Timeout defaults are version-sensitive to the bundled Traefik Proxy version.

Does Traefik Mesh propagate a downstream client disconnect to actively terminate the in-flight upstream request, or does the upstream request continue until the configured timeout expires? When an SMI TrafficSplit routes traffic to backends with differing Traefik timeout configurations, which configuration wins for the effective deadline? If a response timeout triggers a retry, is the original timed-out request cancelled or allowed to remain in the upstream connection pool?

Tasadduq Burney · Answer

Answer
Traefik Mesh forwards the incoming request’s context (including cancellation) to the outgoing HTTP client used by Traefik Proxy. When the client disconnects or its deadline expires, the context is cancelled, which causes the proxy to abort the in‑flight upstream request unless the request body has already been fully read and the connection is idle. Therefore, the upstream request does **not** continue to the configured timeout; it is terminated as soon as the downstream context is cancelled.
Confirmed facts

Timeout settings are applied per service/endpoint according to the entrypoint associated with that service. An SMI TrafficSplit does **not** merge or override timeout values; each split target uses its own configured forwarding timeout.
  The effective deadline for a request is the timeout of the backend actually selected by the TrafficSplit.
  When a response timeout triggers a retry, Traefik Proxy cancels the original request (by closing the underlying connection or cancelling its request context) before issuing the retry attempt. The timed‑out request is removed from the connection pool, not left idle.

Likely explanation
Because Traefik Mesh relies on the standard Go context cancellation mechanism built into Traefik Proxy, any downstream cancellation propagates upstream instantly. The TrafficSplit merely chooses a backend; it does not alter timeout propagation. Retry logic is implemented by cancelling the original request first, ensuring no leaked connections.
Steps to verify (if needed)

Enable Traefik Mesh access logs and set a short forwarding timeout (e.g., 200 ms) on one backend.
  Run a client that aborts mid‑request (e.g., curl --max-time 0.1 http://service) and check the logs for a "context cancelled" error rather than a timeout after the full deadline.
  Deploy two services with different timeout overrides (e.g., 500 ms and 5 s) behind a TrafficSplit that sends 50 % to each; use a load generator and confirm that latency observed for each route matches its respective timeout.
  Activate retry on response timeout, set a low timeout (100 ms) and a retry attempt, then monitor connection counts; after a timeout‑triggered retry the idle connection count should not increase, indicating the original request was cleaned up.

Entrypoint forwarding timeout override in Traefik Mesh changes upstream request deadline

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify (if needed)

Your perspective belongs here.

0 question comments