mcp: better handle 405 on GET requests#1980
Open
nacx wants to merge 3 commits intoenvoyproxy:mainfrom
Open
Conversation
Member
Author
|
@mathetake WDYT about this approach? |
Signed-off-by: Ignasi Barrera <nacx@apache.org>
Signed-off-by: Ignasi Barrera <nacx@apache.org>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1980 +/- ##
==========================================
+ Coverage 84.33% 84.37% +0.03%
==========================================
Files 130 130
Lines 17987 17988 +1
==========================================
+ Hits 15170 15177 +7
+ Misses 1873 1868 -5
+ Partials 944 943 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Member
Author
|
/retest |
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.
Description
Changes how the GET requests are managed when some backends return 405.
The main challenge is that the GET implementation always returns a 202, no matter what the upstream backends return. When all upstream backends return a 405, that translates into an immediate 202 completed, and clients reconnect, causing the constant reconnection loop.
Ideally, when all backends return 405, we should return a 405 as well, but this is challenging: it would require for us to not return the response status until we have received a 405 from all backends, and if some backend does not return and it's just waiting to start streaming events, we may not be able to return the right response code anything until we've received the first event, which may be waiting too long.
This PR addresses it in a different way, by always returning a 202 and keeping the stream open between the client and the gateway, even when all backends return 405, or they return EOF after stopping sending events. This prevents the client reconnection loop and keeps the stream open to send gateway-related notifications, such as tool changes. Even though upstream backends don't have more events to report, the gateway itself may still use it to send notifications, so I think it is OK to keep it open and move the control to the client, and let clients decide when to close the stream or reopen it.
Related Issues/PRs (if applicable)
Fixes #1924
Fixes #1925
Special notes for reviewers (if applicable)
N/A