Repository navigation
an idle keep-alive closes at DEBUG, and an upstream that never answered says so - #5
Merged
Merged
Conversation
…ver answered says so
The shared HTTP handler logged every socket timeout as one WARNING line. Most of
them were an MCP client's keep-alive connection idling past `timeout` between
calls — the timeout doing its job — and a peer with a real problem, or an
upstream that hung, was a line among them. Where the read was now decides:
waiting for the next request line after at least one answer is the idle close,
logged at DEBUG; a socket that never spoke, or a request whose headers or body
never arrived, stays one line at WARNING with the count and the last request
line.
The gate's upstream failures were in the ledger only. They are logged at
WARNING as well, and a timeout is named as one with the limit it ran into
("upstream timeout: no answer within 60s"), so it cannot be read as the
client-side `timed out`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The sidecars' shared HTTP handler logged every socket timeout as one WARNING line. In the work stack's MCP gate most of those lines were an MCP client's keep-alive connection idling past
timeoutbetween calls — the timeout doing its job — and a peer with a real problem, or an upstream that hung, had to be picked out from among them.What changes
common.HttpHandlernotes where the read was. Waiting for the next request line after at least one answer is the idle close: one DEBUG line,idle keep-alive closed peer=… requests_seen=N. A socket that connected and never spoke, or a request whose headers or body never arrived, stays the WARNING it was, with the count and the last request line saying which.gate.pylogs an upstream failure at WARNING as well as writingcall.failed, and names a timeout as one with the limit it ran into —upstream timeout: no answer within 60s— in both, so it cannot be read as the client-sidetimed out. Other failures keep their reason as before.Nothing about the timeouts themselves changes: the same 30 s on the client side, the same
UPSTREAM_TIMEOUTon the relay.Tests
test_an_idle_keep_alive_closes_at_debug_not_as_a_warningreplaces the test that pinned the idle close at WARNING.test_a_body_that_never_arrives_names_the_request_it_belonged_to: the mid-request stall stays a WARNING naming its request.test_a_chat_server_that_hangs_is_a_502_that_says_it_timed_out: a stalled upstream is a 502, the ledger row and a WARNING line both say upstream timeout.The two new behaviours fail without the change.
bash scripts/gate.sh: STACK GATE GREEN.