Skip to content

fix(ack-pay): valibot decimals validator rejects negative values instead of clamping - #155

Open
ygd58 wants to merge 1 commit into
agentcommercekit:mainfrom
ygd58:fix/decimals-clamp-not-validate
Open

fix(ack-pay): valibot decimals validator rejects negative values instead of clamping#155
ygd58 wants to merge 1 commit into
agentcommercekit:mainfrom
ygd58:fix/decimals-clamp-not-validate

Conversation

@ygd58

@ygd58 ygd58 commented Aug 13, 2026

Copy link
Copy Markdown

Fixes #147

The valibot version of paymentOptionSchema used v.toMinValue(0) on the decimals field — a transform that silently clamps a negative number up to 0, rather than a validator that rejects it. This diverged from the zod version of the same schema (z.number().int().nonnegative()), which correctly rejects negative values.

Fix: switched to v.minValue(0), valibot's validating counterpart, so a payment option with a malformed negative decimals value is rejected by both schema implementations instead of being silently "fixed" by the valibot one.

Tests: added a regression test asserting both schemas reject a negative decimals value and agree on valid (zero/positive) values.

Changeset: added (@agentcommercekit/ack-pay, patch).

Verified locally: vitest run src/schemas/decimals.test.ts (3/3 passing — confirmed it fails against the old toMinValue code and passes with the fix), oxlint and oxfmt --check clean.


AI usage disclosure (per AI_POLICY.md): this fix was developed with Claude (Anthropic) assistance — identifying the divergence between the valibot and zod schemas, writing the fix, writing the test, and verifying locally. I reviewed and understand the change: it's a one-word swap (toMinValueminValue) that changes valibot's decimals validation from a silent clamp to a rejection, matching zod's existing behavior.

Summary by CodeRabbit

  • Bug Fixes

    • Payment option decimal values now consistently reject negative numbers.
    • Zero and positive decimal values continue to be accepted across supported validation formats.
  • Tests

    • Added coverage to verify consistent decimal validation behavior.

…ead of clamping

Fixes agentcommercekit#147

The valibot version of paymentOptionSchema used v.toMinValue(0) on the
decimals field - a transform that silently clamps a negative number up
to 0, rather than a validator that rejects it. This diverged from the
zod version of the same schema (z.number().int().nonnegative()), which
correctly rejects negative values.

Switched to v.minValue(0), valibot's validating counterpart, so a
payment option with a malformed negative decimals value is rejected by
both schema implementations instead of being silently "fixed" by the
valibot one.

Added a regression test asserting both schemas reject a negative
decimals value and agree on valid (zero/positive) values. Changeset
added (patch, @agentcommercekit/ack-pay).

AI usage disclosure: this fix was developed with Claude (Anthropic)
assistance - identifying the divergence between the valibot and zod
schemas, writing the fix, writing the test, and verifying locally.
I reviewed and understand the change: it's a one-word swap
(toMinValue -> minValue) that changes valibot's decimals validation
from a silent clamp to a rejection, matching zod's existing behavior.
@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4d707d0b-5484-4f94-b97c-3a58484e5c21

📥 Commits

Reviewing files that changed from the base of the PR and between 0b8fdaa and f542358.

📒 Files selected for processing (3)
  • .changeset/decimals-clamp-fix.md
  • packages/ack-pay/src/schemas/decimals.test.ts
  • packages/ack-pay/src/schemas/valibot.ts

Walkthrough

Valibot now rejects negative paymentOptionSchema.decimals values instead of clamping them to zero. Tests cover both Valibot and Zod schemas. A patch changeset documents the fix.

Changes

Payment option decimal validation

Layer / File(s) Summary
Reject invalid decimal values
packages/ack-pay/src/schemas/valibot.ts, packages/ack-pay/src/schemas/decimals.test.ts, .changeset/decimals-clamp-fix.md
Valibot uses v.minValue(0) for decimals. Tests verify negative values are rejected and zero or positive values are accepted. The changeset records the patch release.
Estimated code review effort: 2 (Simple) ~10 minutes

Mergeability Score: ⚪ Minimal · up to f5423

This localized validation fix rejects malformed negative decimal values consistently and includes regression tests; no actionable merge-blocking risk remains after normal checks and review.

Possibly related PRs

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly states that the Valibot decimals validator now rejects negative values instead of clamping them.
Linked Issues check ✅ Passed The change replaces v.toMinValue(0) with v.minValue(0) and adds regression tests for negative, zero, and positive decimal values as required by issue #147.
Out of Scope Changes check ✅ Passed All changes support issue #147 by updating the validator, adding targeted tests, and documenting the patch release.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: paymentOptionSchema.decimals uses toMinValue (clamps) instead of minValue (validates)

1 participant