mcp: capture upstream http_status in tool-call telemetry (enrich_titles API_ERROR floor)#100
Draft
ArtyETH06 wants to merge 1 commit into
Draft
mcp: capture upstream http_status in tool-call telemetry (enrich_titles API_ERROR floor)#100ArtyETH06 wants to merge 1 commit into
ArtyETH06 wants to merge 1 commit into
Conversation
leadbay_enrich_titles shows a ~7% API_ERROR floor (10/136 calls last 7d). API_ERROR is the catch-all in client.ts mapErrorResponse for any backend non-2xx that isn't 401/402/403/404/429. The error envelope already carries the upstream status at _meta.http_status (client.ts makeError), and the Sentry capture path forwards it via buildBusinessCtx — but the high-volume PostHog product-analytics events (`mcp tool called` / `mcp composite call`) did NOT, so the dashboard couldn't tell whether the floor is 503s, 500s, or a 4xx edge. Observability-only fix: add http_status?: number to ToolCallProps and CompositeCallProps, and forward err._meta.http_status onto both events at the business-error capture sites in server.ts. No retry logic, no change to client.ts request behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
TEST PR from the mcp-analysis / eval skill |
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
1 participant
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.
What
Observability-first step for the
leadbay_enrich_titles~7% API_ERROR floor (10/136 calls last 7d).API_ERRORis the catch-all inpackages/core/src/client.tsmapErrorResponsefor any backend non-2xx that isn't 401/402/403/404/429. The error envelope already carries the upstream status at_meta.http_status(client.tsmakeError, ~L876), and the Sentry capture path forwards it viabuildBusinessCtx(server.tsL832) — but the high-volume PostHog product-analytics events (mcp tool called/mcp composite call) did not. So on the dashboard where the floor was measured, we can't tell whether it's 503s, 500s, or a 4xx edge.The fix (one concern, low risk)
ToolCallProps+CompositeCallPropsgainhttp_status?: number.server.tsforwarderr._meta.http_statusonto both events.No retry logic. No change to
client.tsrequest behavior. This is deliberately observability-only: capture the status first, then let the data confirm which upstream status dominates before deciding whether a retry fix is warranted.enrich_titlesis a composite, so it flows through both events — both now carry the status.Tests
New file
packages/mcp/test/tool-call-http-status.test.tsdrives a tool that throws aLeadbayError-shaped envelope carrying_meta.http_status: 503and asserts the captured tool-call event includeshttp_status === 503.expected undefined to be 503)pnpm -r test(core 380 / promptforge 16 / mcp 383) andpnpm -r typecheckboth green.Follow-up (deferred)
Once a few days of data confirm the dominant status (503 vs 500 vs 4xx), decide whether to add bounded retry/backoff for the transient subset. Not in this PR.