feat(x402): Phase 6 — thread paymentRequestId to authorize (Base)#185
Open
badjer wants to merge 2 commits into
Open
feat(x402): Phase 6 — thread paymentRequestId to authorize (Base)#185badjer wants to merge 2 commits into
badjer wants to merge 2 commits into
Conversation
…p reservation (Base) accounts keys the binding X402 cap reservation (upto sessions) to the challenge's paymentRequestId and releases it at settle (accounts/auth Phase 6). Thread that id through authorize so accounts can store the reservation handle: - AuthorizeParams.paymentRequestId; ATXPAccount.authorize sends it in the /authorize/auto body. - Passed from both call sites — the omni handler (challengeData.paymentRequestId) and the x402 handler (paymentChallenge.paymentRequestId). Additive and backwards-compatible (optional field; an older accounts ignores it and the reservation falls back to TTL-based release). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
packages/atxp-client/package.json was bumped to 0.11.12 with @atxp/common
and @atxp/mpp pinned at 0.11.11, but package-lock.json (and the six sibling
packages pinning @atxp/client at 0.11.10) still record the consistent
0.11.10 workspace state. npm ci therefore fails EUSAGE ("not in sync") on
every run; the workflow's continue-on-error fallback then does a lockfile-less
npm install, which resolves the 0.11.11 pins to the REGISTRY @atxp/common —
so atxp-client typechecks against published types instead of the workspace,
and any PR adding a cross-package type (like AuthorizeParams.paymentRequestId
here) fails typecheck.
Roll atxp-client back to the lockfile's 0.11.10 state: npm ci succeeds again
(zero lockfile churn) and both install paths link the workspace packages.
Version numbers are rewritten from the release tag by release.yaml at publish,
so nothing is lost.
Co-Authored-By: Claude Fable 5 <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.
What
Phase 6 (X402 binding reservation + release), SDK side. Pairs with accounts circuitandchisel/accounts#852 and auth circuitandchisel/auth#281.
accounts keys the binding X402 cap reservation (
uptosessions) to the challenge'spaymentRequestIdand releases it at settle. This threads that id throughauthorizeso accounts can store the reservation handle against it.Changes
AuthorizeParams.paymentRequestId(optional).ATXPAccount.authorizesends it in the/authorize/autorequest body.challengeData.paymentRequestId) and the x402 handler (paymentChallenge.paymentRequestId).Compatibility
Additive and backwards-compatible: the field is optional, so an older accounts simply ignores it and the reservation falls back to TTL-based release. No behavioral change to existing flows.
npm run buildclean; atxp-client + atxp-common unit tests green.🤖 Generated with Claude Code