Repository navigation
fix(agentgateway): state what the viaMuster request timeout bounds; keep 300s - #73
Merged
Merged
Conversation
… ceiling (3600s) muster keeps a tools/call that reports progress alive past spec.timeout up to spec.progress.maxDuration (at most 3600 s); the 300s gateway deadline cut such calls. agentgateway has no per-request idle timeout, so the idle cut stays muster's spec.timeout.
…that it bounds the response start, not progress-kept calls Lab proof: a 360 s call with progress passes the 300s deadline uncut; at a 30s deadline a silent call is cut and a streaming one is not.
teemow
changed the title
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.
Problem
#72 assumed that
agentgateway.viaMusterTimeouts.request(300s) cuts atools/callthat muster v5.40.0 (giantswarm/muster#1487) keeps alive by progress up tospec.progress.maxDuration(3600 s). It does not. The comments on the value, though, said it must cover how long muster lets a call run, which is wrong and pointed to raising it.Root cause
agentgateway's
requestTimeouton the backend is a deadline for the upstream response to start, not for the call to end. muster starts the response with the final answer, or with the event stream at a call's first progress notification. Both happen within the MCPServer'sspec.timeout(up to 300 s). After that, the deadline no longer applies. So300salready covers every call. Raising it would only let a muster that never answers hold a call longer.Proposed solution
viaMusterTimeouts.requeststays at300s.spec.timeoutandspec.progress.maxDuration. Thevia-mustergolden render is updated and a CHANGELOG entry added.Acceptance criteria
viaMuster: trueand the default values, atools/callthat reports progress for longer than 300 s completes through the gateway.viaMusterTimeouts.requeststates how it relates to muster'sspec.timeoutandspec.progress.maxDuration.Testing
The test ran on agentlab-2: agent-platform 4.129.0, muster 5.40.0,
ingress.mode: agentgateway-muster. The calls went through the viaMuster routeagent-platform/agent-platform-mcps(protocol=mcpin agentgateway's access log). The test server's tool runs for N seconds and sends progress every 20 s. It is registered with muster withtimeout: 60andprogress.maxDuration: 900.requestTimeout300s0.11.6-dev.apm72.2from the lab registry),300s30s30supstream call timeoutagentlab platform-testis green on the branch chart and again after restoring the release (13 PASS each).make verify-renderis green with helm v3.17.3, the version CI pins.