fix(ack-pay): reject a negative decimals instead of clamping it - #151
fix(ack-pay): reject a negative decimals instead of clamping it#151crazywriter1 wants to merge 1 commit into
Conversation
`paymentOptionSchema` validated `decimals` with the valibot `toMinValue(0)` action, which is a transformation that clamps rather than a validation that rejects, so `decimals: -2` parsed successfully as `decimals: 0`. `decimals` scales `amount`, so clamping turned an invalid payment option into a valid one asking for a different sum, on the verification path as well since `verifyPaymentRequestToken` parses token payloads with this schema. The zod schema already rejected the same input via `nonnegative()`.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe payment option schema now rejects negative ChangesPayment decimals validation
Estimated code review effort: 2 (Simple) | ~10 minutes Mergeability Score: ⚪ Minimal · up to The change makes negative decimal values fail validation instead of being silently converted to zero, with a focused test covering the behavior. No actionable merge-blocking risk remains beyond normal checks and review. Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Closing as a duplicate of #149, which makes the same change and landed first. Sorry. |
Problem
paymentOptionSchemavalidatesdecimalswith valibot'stoMinValue(0). That is a transformation that clamps, not a validation that rejects, so a negative value parses successfully as0:decimalsscalesamount, so this does not just normalize a stray value — it turns an invalid payment option into a valid one asking for a different sum, and it does so silently. It applies on the verification path too, sinceverifyPaymentRequestTokenparses token payloads with this schema.The zod schema next to it already uses
z.number().int().nonnegative(), so the two validators disagreed about which payment requests are well-formed. Every other bound in the repo uses the validating form (v.minValue), which is what makes this look like a slip rather than a decision.Fix
v.toMinValue(0)becomesv.minValue(0), plus a test that a negativedecimalsis rejected. After the change both validators reject the same input and valid values still parse.This is a breaking change in the sense that input previously accepted now fails, which is the point: accepting it was the bug. Nothing in the repo passes a negative
decimals, so no existing caller breaks.Testing
pnpm checkpasses.AI usage disclosure
Per AI_POLICY.md: this change was AI-assisted using Cursor.
Summary by CodeRabbit
Bug Fixes
Tests