chore(deps): bump @aibtc/tx-schemas to ^1.1.0 - #629
Conversation
Closes #492. The bump is additive for the symbols this repo consumes, so no type migration was needed: - TerminalReason is byte-identical between 0.7.0 and 1.1.0 - HttpPaymentStatusResponse only gains optional fields (lastOccupant, quarantinedNonces); the status enum and terminalReason are unchanged - All three parse sites use safeParse against a $strip schema, so added optional fields cannot reject existing relay responses Verified: tsc clean, 543 tests pass, zod dedupes to a single 4.3.6. Parse behavior compared side by side against 0.7.0 on representative payloads (minimal, terminal, full body, unknown extra key) with no divergence.
arc0btc
left a comment
arc0btc
left a comment
There was a problem hiding this comment.
Reviewed the diff (package.json/package-lock.json bump @aibtc/tx-schemas 0.7.0 → ^1.1.0) and the PR description's verification work.
[note] Good diligence here — the side-by-side parse comparison table against a staged 0.7.0 is exactly the right way to de-risk a lockfile-only major bump, and calling out that both FAIL rows are pre-existing 0.7.0 behavior (not new regressions) is the detail that actually matters for a schema-version bump like this. npm ls zod dedup check also rules out the usual "two copies of zod" failure mode for these bumps.
[question] You flagged that x402-payment-state.ts / HttpPaymentStatusResponse has no direct test coverage today — is the follow-up to add coverage there tracked anywhere, or should this PR spawn that issue on merge?
CI is green (Analyze x2, CodeQL, Snyk, test), all 4 imported symbols confirmed compatible (byte-identical TerminalReason, additive-only optional fields on HttpPaymentStatusResponse), consistent with the other Wave 2 repos already on ^1.1.0. Approving.
2 participants
Closes #492.
Brings mcp-server in line with the other Wave 2 repos (relay, agent-news, x402-api, landing-page), which moved to
^1.1.0.The migration wasn't needed
#492 deferred this from C2 on the assumption it was "a real type-migration, not a lockfile-only bump." That turned out not to hold for the four symbols this repo imports:
TerminalReason— byte-identical between 0.7.0 and 1.1.0HttpPaymentStatusResponse— only gains optional fields (lastOccupant,quarantinedNonces). Thestatusenum andterminalReasonshape are unchanged.All three parse sites (
x402-payment-state.ts) usesafeParseagainst a$stripschema, so added optional fields can't reject responses the running relay already emits.Verification
npm run build— clean, zero type errorsnpm test— 543 passed, 4 skippednpm ls zod— dedupes to a singlezod@4.3.6, no duplicate copyterminalReason: nullterminalReasonenum memberpay_prefix)No divergence. The two FAIL rows are pre-existing 0.7.0 behavior, not regressions — the schema has always required
terminalReasonto be omitted rather thannull, and always enforced thepay_id prefix.Note on coverage
No test file currently exercises
x402-payment-state.tsorHttpPaymentStatusResponse, so the green suite doesn't by itself cover this path — the side-by-side parse comparison above is what backs the runtime claim. Worth a follow-up to add cases aroundresolveCanonicalPaymentStatus.