🐛 Check integer multipleOf exactly instead of via a lossy float

[frenck]

Breaking change

None that affects a correct schema: values only validate more correctly. A large integer that used to slip past multipleOf now fails, matching jsonschema. One deliberate, documented divergence from jsonschema is kept: a float like 0.3 is still accepted as a multiple of 0.1 (the user-friendly reading), where jsonschema's exact-binary arithmetic rejects it.

Proposed change

The multipleOf check divided two f64s and accepted the result within a relative tolerance (1e-9 * ratio). That tolerance grows without bound as the value grows, and a large integer loses precision the moment it becomes an f64, so an odd integer such as 10000000000000001 validated as a multiple of 2.

When both the value and multipleOf are integers the check is now exact integer modulo, done on i128 so it also covers big integers past i64. When either operand is a float it stays best-effort within floating-point precision, but the tolerance is scaled to the operands' magnitude (a few ULPs of the nearest multiple) rather than the ratio, so 3.0000001 is no longer a multiple of 1.0 while 0.3 still counts as a multiple of 0.1 (binary rounding). Verified against the jsonschema reference for the integer cases.

Found by a differential sweep against jsonschema.

Type of change

• Dependency or tooling upgrade
• Bugfix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Deprecation (replaces or removes a feature, with a migration path)
• Breaking change (a fix or feature that changes existing behavior)
• Code quality, refactor, or test-only change
• Documentation only

Additional information

• This PR fixes or closes issue: None
• This PR is related to: ✨ Expand JSON Schema keyword support (pattern, multipleOf, tuple items, and more) #190
• Link to a separate documentation pull request: None

Checklist

• I have read the AI Policy, and this pull request was not created by an autonomous agent.
• I fully understand the code in this pull request and can explain every line, including any AI-assisted changes.
• The change is covered by tests, and uv run pytest passes locally. A pull request cannot be merged unless CI is green.
• uv run ruff check . and uv run ruff format --check . pass.
• cargo fmt --check and cargo clippy --all-targets -- -D warnings pass.
• Round-trip fidelity is preserved: an unmodified document still re-emits byte-for-byte.
• No commented-out or dead code is left in the pull request.

If the change is user-facing:

• Documentation under docs/ is added or updated, and docs/verify_examples.py still passes.

[coderabbitai]

Warning

Review limit reached

@frenck, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 34 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 95933f6c-990d-4a1a-b7cb-ef65ba2e06db

📥 Commits

Reviewing files that changed from the base of the PR and between dfa7ec3 and 5106579.

📒 Files selected for processing (2)

• src/schema/mod.rs
• tests/features/test_schema.py

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing frenck/schema-multipleof (5106579) with main (dfa7ec3)}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.71%. Comparing base (88e74b6) to head (5106579).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #196      +/-   ##
==========================================
+ Coverage   92.46%   92.71%   +0.25%     
==========================================
  Files          40       40              
  Lines       11871    12087     +216     
==========================================
+ Hits        10976    11206     +230     
+ Misses        895      881      -14     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR fixes a correctness bug in the JSON Schema validator's multipleOf check (introduced in the related #190). The previous implementation divided two f64s and accepted the result within a relative tolerance (1e-9 * ratio), which grew unboundedly with magnitude and lost integer precision once a value became an f64 — so an odd integer like 10000000000000001 incorrectly validated as a multiple of 2. The fix performs an exact integer-modulo check (on i128, covering big integers past i64) when both operands are integers, and keeps a tighter, magnitude-scaled best-effort tolerance for float operands.

Changes:

• Rework is_multiple_of to take the raw Values and use exact i128 modulo when both value and multipleOf are integers, falling back to a ULP-scaled float comparison otherwise.
• Add an as_i128 helper that extracts an exact integer from Value::Int/Value::BigInt.
• Add regression tests covering large odd integers, big integers past i64, genuine multiples, and a non-integral float multiple.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/schema/mod.rs	Replaces the lossy float multipleOf check with exact i128 integer modulo plus a tightened float fallback; adds as_i128 helper.
tests/features/test_schema.py	Adds test_multiple_of_is_exact_for_integers covering exact integer, big-integer, and non-integral-float cases.

I verified the call-site signature update (single caller), the Value enum variants used by as_i128, the modulo-by-zero guard, and the float tolerance behavior for the documented cases (0.3/0.1 accepted, 3.0000001 rejected). The change is correct and well-scoped; my only note is a nit about pinning the intentional float-acceptance divergence with a regression test.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.