Traefik Mesh timeout propagation and connection pooling behavior

Connection State After Transport Timeouts

When a timeout defined in a Traefik Mesh Transport resource is triggered, the sidecar proxy does not return the connection to the pool. Because a timeout at the Transport level indicates a failure in the underlying TCP/TLS handshake or a breach of the response body duration, the connection is marked as invalid and is closed.

Returning a connection to the pool after a timeout would risk "leaking" a corrupted or desynchronized stream into a subsequent request. Consequently, the proxy severs the socket to ensure the next request initiates a fresh handshake.

Cancellation Signals and Backend Propagation

The mechanism for notifying the backend service of a timeout depends entirely on the protocol being used by the mesh:

• HTTP/2: The sidecar sends a RST_STREAM frame. This allows the underlying TCP connection to remain open for other requests while signaling the backend to stop processing that specific stream.
• HTTP/1.1: Since HTTP/1.1 lacks a native stream-level cancellation mechanism, the sidecar must close the TCP connection. The backend service will only detect this cancellation when it attempts to write the response to the socket and receives a "connection reset by peer" or a broken pipe error.

Likely Behavioral Implications

There is a functional decoupling between the mesh-defined timeout and the application-level socket timeout. If the Traefik Mesh timeout is shorter than the backend's internal timeout, a "ghost request" scenario occurs: the sidecar returns a timeout error to the client and closes the connection, but the backend service continues to consume CPU and memory resources until its own internal timeout expires or it attempts to send data back to the closed socket.

Verification Steps

To confirm how your specific version of Traefik Mesh is handling these terminations, use the following scoped verification methods:

1. Packet Analysis: Use tcpdump on the sidecar container to verify if a FIN or RST packet is dispatched immediately upon the timeout trigger.
2. Backend Monitoring: Perform a thread dump of the backend service immediately after a mesh timeout. If the request thread remains in a RUNNABLE state, the cancellation signal is not being propagated effectively.
3. Log Inspection: Check proxy logs for context canceled entries, which indicate the proxy has stopped waiting for the backend.

Diagnostic Detail Needed: To provide a more precise recommendation on timeout alignment, please specify if your mesh is utilizing HTTP/1.1 or HTTP/2 for backend communication.