fix(sdk): correct BigNum zero-precision formatting edge cases#2201
fix(sdk): correct BigNum zero-precision formatting edge cases#2201jenish-25 wants to merge 1 commit into
Conversation
Two formatting bugs in BigNum surfaced with a zero argument:
- toFixed(0) returned a value with a dangling decimal delimiter
('123.', '0.', '-5.') instead of the integer portion ('123', '0',
'-5'). Return the left side directly when precision is zero.
- toNotional() ignored a decimalOverride of 0 because the value was
folded into a truthiness check, so whole-dollar formatting fell back
to the 2-decimal default. Test for presence (!== undefined) instead.
Adds unit tests for both cases to tests/bn/test.ts.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughModified BigNum.toFixed to return only the integer portion when fixedPrecision is zero or negative, and updated BigNum.toNotional to treat a decimalOverride of 0 as an explicit custom precision value rather than falsy. Added corresponding unit tests validating both edge cases. ChangesBigNum Precision Handling
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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
Fixes two formatting bugs in
BigNum(sdk/src/factory/bigNum.ts) that surface when a zero argument is passed.1.
toFixed(0)leaves a dangling decimal delimitertoFixedalways appends the delimiter + fractional part, so zero precision produced a malformed string:Fix: when precision is zero there is no fractional part, so return the integer portion directly.
2.
toNotional()ignores adecimalOverrideof0The
usingCustomPrecisioncheck foldeddecimalOverrideinto a truthiness test, so0(a legitimate value meaning "whole-dollar formatting") was treated as "not provided" and fell back to the 2-decimal default:Fix: test
decimalOverride !== undefinedinstead of truthiness.prettyPrintalready handles0correctly downstream.Tests
Added two cases to
sdk/tests/bn/test.tscovering both fixes (and asserting the non-zero / default paths are unchanged). AllBigNumtests pass, andprettier --checkis clean.Summary by CodeRabbit
0decimal override as an intentional setting, preserving expected whole-number output.