fix(wallet): hold reservation on ambiguous x402 settlement - #129
Open
GentechLabs wants to merge 1 commit into
Open
fix(wallet): hold reservation on ambiguous x402 settlement#129GentechLabs wants to merge 1 commit into
GentechLabs wants to merge 1 commit into
Conversation
x402 is fire-and-forget per request. If the shared 30s budget (or parent abort signal) expires mid-handshake after the signed, paid request is dispatched, the server may already have settled the payment on-chain — even though we never saw the response. Previously the caller's finally block released the reservation unconditionally on this ambiguous-failure path, so totalReserved() under-counted and the next hold() saw headroom that didn't exist. Now postWithPayment tracks whether it dispatched the signed request and surfaces settlementAmbiguous on abort. Each Modal paid handler (create, exec, status, terminate) keeps the reservation held and invalidates the balance cache when the outcome is ambiguous — erring tight, never loose. A genuinely-absent spend self-heals on the next balance refetch. Ref BlockRunAI#128
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.
Closes #128
Problem
x402 is fire-and-forget per request — there's no real "hold" on-chain.
postWithPaymentputs a single 30sAbortControlleracross the whole handshake, and the signed, paid request shares that same signal. If the budget expires during the paid request, the fetch aborts and throws. The caller'sfinallythen released the reservation unconditionally (modal.tsrelease in the finally block).But an aborted paid request may already have been received and settled on-chain. In that case the money is gone yet the reservation is released anyway, so
totalReserved()under-counts and the nexthold()sees headroom that doesn't exist.Fix
postWithPaymentnow tracks whether it actually dispatched the signed request (paidRequestDispatched) and surfaces asettlementAmbiguousflag on the abort/error path. Each Modal paid handler (create, exec, status, terminate) then:A genuinely-absent spend self-heals at the next balance refetch. This mirrors the
hpp-io/x402-mcp-bridgev0.1.15 pattern cited in the issue.Verification
npm run buildpasses.test/local.mjsasserts the ambiguity flag is surfaced and all four Modal paid handlers route ambiguous settlements to a hold (not a release). Test passes.npm testhas no new failures (the pre-existing failures are unrelated environment/CLI/session tests, none touchmodal.ts).Note
This fills the same class of local-accounting drift the reservation module already guards against on the concurrency path — now also covered on the ambiguous-failure path. Happy to adjust if the maintainer prefers a different default.