fix: allow null txHash in SettleResult for already-settled retries#165
Merged
fix: allow null txHash in SettleResult for already-settled retries#165
Conversation
Auth is adding a carve-out on /settle/x402 that returns 200 with
{ alreadySettled: true, txHash: null, ... } when the CDP facilitator
rejects a retry with "duplicate transaction" (see auth PR for details).
The SDK's SettleResult.txHash was typed as string (non-nullable), which
would be a lie the moment that auth change ships.
Loosen the type to string | null, add an optional alreadySettled flag,
and update the two log interpolations in protocol.ts and atxpExpress.ts
to render "<already-settled>" when txHash is null instead of the word
"null". Behavior on the happy path (txHash: string) is unchanged.
Co-Authored-By: Claude Opus 4.7 (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
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.
Summary
Loosens
SettleResult.txHashfromstringtostring | null, adds an optionalalreadySettledflag, and updates the two log interpolations that referencetxHashto render<already-settled>when it's null.Why
A companion auth PR (circuitandchisel/auth#new) adds a carve-out on
POST /settle/x402that returns200 OKwith{ alreadySettled: true, txHash: null, ... }when the CDP facilitator reportsduplicate transactionon a retry of an already-settled payload. TodaySettleResult.txHashis typed as non-nullablestring, which would be a lie the moment that auth change ships.Nothing in the SDK reads
txHashbeyond twologger.infotemplate-string interpolations (protocol.ts:233,atxpExpress.ts:153), so runtime behavior is unchanged on the happy path. This PR just tells the truth at the type layer and makes the log line render nicely when it's null.What changed
packages/atxp-server/src/protocol.ts—SettleResult.txHash: string→string | null, add optionalalreadySettled?: boolean, and update log interpolation to${result.txHash ?? '<already-settled>'}.packages/atxp-express/src/atxpExpress.ts— same log-interpolation nil-coalesce on the middleware'stxHash=...log line.packages/atxp-server/src/protocol.test.ts— one new test: auth returns{ txHash: null, alreadySettled: true, ... }, SDK surfaces it as-is without crashing.Ordering / deploy safety
txHash: null, SDK's old type castsas SettleResult— JS runtime is fine (${null}renders as"null", ugly but no crash), the only consumers are log lines. Also safe.Test plan
npx vitest run src/protocol.test.ts(atxp-server) — 26 passed (25 original + 1 new)npx vitest run(atxp-express) — 45 passed🤖 Generated with Claude Code