fix: track HTTP status code errors in context for observability #1630
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
The remote server's
error_categorizer.gouses context to extract GitHub API errors for observability metrics. However, when API calls succeed but return unexpected HTTP status codes (e.g., 404, 422, 500), the errors were returned viautils.NewToolResultErrorwhich bypasses the context-based error tracking.This resulted in 100% tool call success rates in observability even when errors occurred.
Root Cause
There are three categories of errors in the tool handlers:
Parameter validation errors (e.g.,
RequiredParamfailures) - These correctly useutils.NewToolResultErroras they are user input errors, not GitHub API errors.GitHub API client errors (when
err != nilafter API call) - These mostly useghErrors.NewGitHubAPIErrorResponseand are tracked correctly.HTTP status code errors (when API succeeds but returns non-2xx) - These were using
utils.NewToolResultErrorand were NOT being tracked.Solution
Add a new helper function
NewGitHubAPIStatusErrorResponsethat:NewGitHubAPIErrorResponseThen systematically updated all tool files to use this new pattern.
Changes
New Function in
pkg/errors/error.goFiles Updated
Relation to Existing PRs
This PR addresses the bulk of the error tracking issue that PRs #1566 and #1570 are also addressing:
NewGitHubGraphQLErrorToCtxand fixes a few issues.go errorsGitHubRawAPIErrortype for raw client errors and fixes GetFileContentsThis PR focuses on the ~69 HTTP status code error paths across all tool files that were not being tracked. After this PR merges:
Testing
NewGitHubAPIStatusErrorResponseNotes
utils.NewToolResultError- they are user input errors, not API errorsio.ReadAllfailures) continue to useutils.NewToolResultErrorFromErr- they are not GitHub API errorsresp(GitHub Response) andctxare tracked