test(mcp_impl): pin parseBalancesJson float64 truncation bug (failing)#142
test(mcp_impl): pin parseBalancesJson float64 truncation bug (failing)#142gfyrag wants to merge 1 commit into
Conversation
JSON numeric values reach the MCP `evaluate` tool as float64 (Go's default for unmarshalling into `any`), and parseBalancesJson currently funnels them through `big.NewFloat(amount).Int(new(big.Int))` — which silently truncates fractional parts and rounds values past the exact- integer range of float64 (±(2^53 - 1)). For a financial DSL, silent corruption of balance amounts is not acceptable: the handler should reject any non-integer or unsafely- large value so the caller is forced to switch to a safer encoding. This commit introduces a failing white-box test `TestParseBalancesJsonRejectsNonIntegerAmounts` and `TestParseBalancesJsonRejectsUnsafelyLargeAmounts` that pin the bug. The third test (`TestParseBalancesJsonAcceptsExactIntegerAmounts`) documents the expected happy path and passes today. CI is intentionally red on this branch. The fix is in a stacked PR that targets this branch — merging it flips the failing tests green. Flagged by CodeRabbit during review of #139. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
WalkthroughAdded unit test file ChangesparseBalancesJson Test Coverage
🎯 1 (Trivial) | ⏱️ ~3 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Summary
Failing regression tests demonstrating a silent corruption bug in
internal/mcp_impl/handlers.go::parseBalancesJson. CI is intentionallyred on this branch — see the stacked fix PR below.
JSON numeric values reach the MCP
evaluatetool asfloat64(Go'sdefault when unmarshalling into
any). The handler converts them withbig.NewFloat(amount).Int(new(big.Int)), which:100.9becomes100.±(2^53 - 1)cannot belosslessly represented as a
float64, so the integer the caller meantis gone before this handler ever sees it.
For a financial DSL these are not acceptable behaviors. The handler
should reject any value that isn't representable as an exact integer
in float64 precision.
Stack
mainMerging the fix flips the failing tests green.
Test plan
TestParseBalancesJsonRejectsNonIntegerAmountsfails today (100.9 is silently truncated to 100).TestParseBalancesJsonRejectsUnsafelyLargeAmountsfails today (1e18 is silently accepted).TestParseBalancesJsonAcceptsExactIntegerAmountspasses (sanity).🤖 Generated with Claude Code