Surface the request id when a run fails - #14
Merged
Conversation
Every /v1/run response has always carried X-Anyapi-Request-Id, including failures, but this client read only the JSON body and printed error.message. So `anyapi run` on a failed call printed a bare "all providers failed" with no handle on it. On 2026-08-26 a customer filed five bug reports through `anyapi report-bug`; four of them said "no result file or request id was produced", and each had to be traced back to a stored request from a customer id and a timestamp. The id was on the wire the whole time. ApiError now carries it and renders `all providers failed (request <id>)`. The anyapi-run skill says where to find it on a FAILED run, which is the gap that produced the empty reports: it already told an agent to pass --request-id without saying where to get one when the run never returned a result. The gateway half shipped in getanyapi-com/anyapi#807, which also adds requestId to the error body. This reads the header instead, so it works against any gateway version. Co-Authored-By: Claude Opus 5 (1M context) <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
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.
Every
/v1/runresponse has always carriedX-Anyapi-Request-Id, including failures. This clientread only the JSON body and printed
error.message, so a failed run printed a bareall providers failedwith no handle on it.On 2026-08-26 a customer filed five bug reports through
anyapi report-bug. Four said "no resultfile or request id was produced", and each had to be traced back to a stored request from a
customer id and a timestamp. The id was on the wire the whole time.
What changed
ApiErrorcarriesrequestId, read from the response header inrequestJson.all providers failed (request 0a508adc-...); unchanged when the responsecarries no id, so non-run routes look exactly as before.
REQUEST_ID_HEADERinconstants.tsso the header name has one owner.skills/anyapi-run/SKILL.mdnow says where to find the id on a FAILED run. That is the gap thatproduced the empty reports: it told an agent to pass
--request-idwithout saying where to getone when the run never returned a result.
Tests
__tests__/run.test.tsgains two cases, proven to fail without the fix (revertingsrc/leavesTests 1 failed | 97 passed):npm test98 passed,npm run buildclean.Ecosystem
The gateway half shipped in getanyapi-com/anyapi#807, which also adds
requestIdto the errorbody. This reads the header instead, so it works against any gateway version and does not depend
on that deploy. No discovery contract, command name, option, or output shape changed, so the
handwritten discovery reader and the other bundled skills are untouched.
Version bumped to 0.8.1; tag after merge to publish.
🤖 Generated with Claude Code