Make the on-ramp session failure legible (signing vs upstream, real status) - #669
Open
nategeier wants to merge 1 commit into
Open
Make the on-ramp session failure legible (signing vs upstream, real status)#669nategeier wants to merge 1 commit into
nategeier wants to merge 1 commit into
Conversation
…and the real status
A bare 502 for every failure mode cost two rounds of guessing while wiring
the on-ramp to a new CDP account. The route caught a JWT-signing throw and
an upstream rejection in the same block, so a malformed API key secret and
a project without Onramp access were indistinguishable from outside.
Now:
· signing is its own try — a bad CDP_API_KEY_SECRET returns 503 stage:'sign'
with the shape error (never the credential itself)
· an upstream non-2xx returns stage:'cdp' + upstreamStatus, and the body is
LOGGED, never returned (it can carry account detail)
· the chip renders that inline: "…(CDP 404)" instead of a dead end
The status is the one fact that separates the cases: 401 the key is
rejected, 403 the key is fine but the project has no Onramp access, 404 the
API surface is not provisioned for that account at all, 400 our payload.
Found with it immediately: prod returns CDP 404 while the identical code and
URL mint a token fine against a different account's key — so the endpoint is
right and the account is the variable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Why
A bare
502for every failure mode cost two rounds of guessing while wiring the on-ramp to the new CDP account. The route caught a JWT-signing throw and an upstream rejection in the same block, so a malformed API key secret and a project without Onramp access looked identical from outside.What changes
try— a badCDP_API_KEY_SECRETreturns503stage:'sign'with the shape error, never the credential.stage:'cdp'+upstreamStatus. Coinbase's body is logged, never returned (it can carry account detail).ClarifyChipsrenders it inline —"…(CDP 404)"instead of a dead end. This is the one screen an operator actually sees while wiring it up.The status is the fact that separates the cases:
Found with it immediately
Prod returns CDP 404 — while the identical code and URL mint a token successfully against a different account's key. So the endpoint is correct and the account is the variable. That's an Onramp-provisioning problem, not a credential-format one.
Gates: tsc + build clean. No behaviour change on the success path.
🤖 Generated with Claude Code