fix(diagnostics): classify HTTP timeouts and string-wrapped 5xx as known codes#469
Merged
Conversation
Deploying mcpproxy-docs with
|
| Latest commit: |
1d3e4cd
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://cf2e7cb2.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://fix-classifier-http-timeout.mcpproxy-docs.pages.dev |
2 tasks
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 26144226306 --repo smart-mcp-proxy/mcpproxy-go
|
Dumbris
pushed a commit
that referenced
this pull request
May 20, 2026
…king Error Slow remote upstreams (notably hf.co/mcp under load) routinely miss a single 5-second health-check window without actually being down. The previous code flipped the server to Error on the very first miss, which caused two visible bugs: 1. The Web UI's tools list went empty for ~30-60s every time the user toggled a tool, because the post-toggle re-fetch hit the State=Error window where StateView returns no tools. 2. Combined with the unclassified-error code (PR #469), the user saw a red "Server Error / MCPX_UNKNOWN_UNCLASSIFIED" alert that paid no real-world dividend — by the next 30s tick the server was Ready again. Add a small consecutive-failure counter to the managed Client. Transient errors (deadline exceeded, timeout, context canceled) require healthCheckFailureThreshold=3 misses (~90s) before flipping Error. Hard errors (connection refused, no such host, network unreachable, etc.) bypass the counter and trigger Error on the first miss — those are real outages and waiting helps no one. A successful health check or a fresh Connect() resets the counter to zero. Tests cover all four behaviors: tolerated transient, immediate hard, success-resets, and connect-resets. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…own codes
The HTTP transport adapter wraps context.DeadlineExceeded and non-2xx
responses as plain "transport error: ..." strings before bubbling them up.
The typed errors.Is / statusError paths the classifier relied on never
fire for those, so every hf.co timeout or 504 surfaced to the UI as
MCPX_UNKNOWN_UNCLASSIFIED ("Server Error") even though the cause was a
well-known transient upstream condition.
Add two recovery rules in classifyHTTP:
- context.DeadlineExceeded on http transport -> new MCPX_HTTP_TIMEOUT
(severity: warn — usually transient, not a config bug)
- substring "context deadline exceeded" on http transport -> same
- "request failed with status NNN" / "notification failed with status NNN"
-> route through DiagnoseHTTPStatus so 401/403/404/5xx all get their
existing typed codes
Tests cover both the typed and stringified forms taken verbatim from
production server-hugginface.log.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Dumbris
force-pushed
the
fix/classifier-http-timeout
branch
from
fc13dfe to
1d3e4cd
Compare
Dumbris
added a commit
that referenced
this pull request
May 20, 2026
…king Error (#470) Slow remote upstreams (notably hf.co/mcp under load) routinely miss a single 5-second health-check window without actually being down. The previous code flipped the server to Error on the very first miss, which caused two visible bugs: 1. The Web UI's tools list went empty for ~30-60s every time the user toggled a tool, because the post-toggle re-fetch hit the State=Error window where StateView returns no tools. 2. Combined with the unclassified-error code (PR #469), the user saw a red "Server Error / MCPX_UNKNOWN_UNCLASSIFIED" alert that paid no real-world dividend — by the next 30s tick the server was Ready again. Add a small consecutive-failure counter to the managed Client. Transient errors (deadline exceeded, timeout, context canceled) require healthCheckFailureThreshold=3 misses (~90s) before flipping Error. Hard errors (connection refused, no such host, network unreachable, etc.) bypass the counter and trigger Error on the first miss — those are real outages and waiting helps no one. A successful health check or a fresh Connect() resets the counter to zero. Tests cover all four behaviors: tolerated transient, immediate hard, success-resets, and connect-resets. Co-authored-by: Claude Code <noreply@anthropic.com>
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
2 participants
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.
Summary
Investigating why disabling tools in the huggingface server surfaced a scary "Server Error / MCPX_UNKNOWN_UNCLASSIFIED" alert, I found the toggle itself works (200 OK), but the upstream's HTTP transport occasionally times out against hf.co/mcp. When that happens during the post-toggle re-fetch, the error reached the user wrapped as plain text — the classifier's typed paths (
errors.Is,*statusError) never fired, so it fell through toUNCLASSIFIED.This PR adds two recovery rules in
classifyHTTP:context.DeadlineExceededon http transport → newMCPX_HTTP_TIMEOUT(severity: warn — transient by nature)"context deadline exceeded"on http transport → same code (catches the string-wrapped form the upstream layer emits)"request failed with status NNN"/"notification failed with status NNN"→ routed through the existingDiagnoseHTTPStatus(int)so 401/403/404/5xx all get their typed codes (no more "UNCLASSIFIED" for plain-string 504s)Tests are taken verbatim from
~/Library/Logs/mcpproxy/server-hugginface.logso the rules cover the exact wire shape the field produces.Why this matters
MCPX_UNKNOWN_UNCLASSIFIEDrenders as red "Server Error" with no remediation.MCPX_HTTP_TIMEOUTandMCPX_HTTP_5XXalready have catalog entries with calmer messaging ("usually transient", "upstream status page link"), andHTTPTimeoutisSeverityWarnso the UI can choose a yellow/degraded badge instead of a red error.This is half of the user-visible fix discussed in the investigation thread. The other half — don't flap the server to
Errorstate on a single 5-second health-check miss — is being addressed in a separate PR.Test plan
go test ./internal/diagnostics/ -race— all green, including the three new cases (TestClassify_HTTP_Timeout,TestClassify_HTTP_TimeoutStringWrapped,TestClassify_HTTP_StatusFromText)go build ./...cleango test ./internal/runtime/supervisor/ -race— green (no churn on attach path)🤖 Generated with Claude Code