Fix STNumber serialization and add counterparty signing helper functions #3191
Conversation
WalkthroughSTNumber normalization and rendering updated with 64-bit mantissa bounds and stricter overflow/underflow checks; Loan model field renamed; many TRANSACTION_RESULTS codes added; Wallet gained counterparty LoanSet signing/combining helpers and multisign-aware signing utilities; tests, fixtures, CI docker command, and HISTORY entries updated. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ripple-binary-codec/src/enums/definitions.json (1)
733-742: UpdateLoan.tsto usePreviousPaymentDueDateinstead ofPreviousPaymentDate.The field was renamed in
definitions.json(line 734) but the TypeScript model atpackages/xrpl/src/models/ledger/Loan.ts(line 108) still references the old name. Update the field name and consider whether the JSDoc comment should also be clarified to match the new semantic meaning ("when the previous payment was due" vs. "when it was made").
🤖 Fix all issues with AI agents
In `@packages/ripple-binary-codec/src/enums/definitions.json`:
- Around line 3645-3660: Update the failing test that still expects the removed
terNO_DELEGATE_PERMISSION code: in delegateSet.test.ts replace any
assertion/expectation using the string 'terNO_DELEGATE_PERMISSION' (or its
numeric -85) with the new error code 'tecNO_DELEGATE_PERMISSION' (value 198) so
the test checks for the updated code name/value returned by the transaction;
search for references in the test (the expect/assert block around the
delegateSet result) and swap the identifier accordingly.
In `@packages/ripple-binary-codec/src/types/st-number.ts`:
- Around line 98-125: The normalize() flow can still produce an exponent >
MAX_EXPONENT for huge inputs (e.g. "1e40000"); after the existing
normalization/shrink/grow loops (but before returning or doing int64-specific
shrinking), add an explicit upper-bound check that if exponent > MAX_EXPONENT
the function throws an Error (similar to the existing 'Mantissa and exponent are
too large' case). Ensure you reference the MAX_EXPONENT constant and perform
this guard in normalize() so no out-of-range exponent is returned or serialized.
🧹 Nitpick comments (1)
packages/ripple-binary-codec/test/st-number.test.ts (1)
27-31: Rename the duplicate test title for clearer output.
Two tests share the exact name “-ve normal value”, which makes failures harder to attribute. Consider a more specific label for one of them.Also applies to: 87-91
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/xrpl/src/Wallet/counterpartySigner.ts`:
- Around line 1-3: The import list includes an unused symbol `decode` which
causes a TS6133 CI failure; remove `decode` from the import statement (leaving
`encode` and `stringify`) in the top of counterpartySigner.ts so the module only
imports used symbols and the TypeScript build error is resolved.
Patel-Raj11
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
CONTRIBUTING.md (2)
80-80: Documentation inconsistency with the updated command.Line 80 still describes
-c 'rippled -a'as the bash command, but the actual command on line 67 now includesmkdir -p /var/lib/rippled/db/ &&beforerippled -a. Update the documentation to match.📝 Suggested fix
-* `-c 'rippled -a'` provides the bash command to start `rippled` in standalone mode from the manual entrypoint +* `-c 'mkdir -p /var/lib/rippled/db/ && rippled -a'` creates the database directory and starts `rippled` in standalone mode from the manual entrypoint
109-109: Browser Tests Docker command missing themkdirfix.The Browser Tests section still uses
-c 'rippled -a'without themkdir -p /var/lib/rippled/db/workaround that was added to the Integration Tests command on line 67 and in the CI workflow.📝 Suggested fix
-docker run -p 6006:6006 --rm -it --name rippled_standalone --volume $PWD/.ci-config:/etc/opt/ripple/ --entrypoint bash rippleci/rippled:develop -c 'rippled -a' +docker run -p 6006:6006 --rm -it --name rippled_standalone --volume $PWD/.ci-config:/etc/opt/ripple/ --entrypoint bash rippleci/rippled:develop -c 'mkdir -p /var/lib/rippled/db/ && rippled -a'
🤖 Fix all issues with AI agents
In `@packages/ripple-binary-codec/test/st-number.test.ts`:
- Around line 168-173: The test description is misleading: the it(...) currently
says "underflow returns zero (value too small)" but the code asserts that
STNumber.from throws an Error('Underflow: value too small to represent'); update
the it(...) title to reflect that it expects an underflow error (for example
"underflow throws error (value too small to represent)") so the test name
matches the asserted behavior; keep the assertion using STNumber.from and the
exact error message 'Underflow: value too small to represent'.
In `@packages/xrpl/src/models/ledger/Loan.ts`:
- Around line 105-108: Update the JSDoc for the PreviousPaymentDueDate field to
reflect the new semantics: change the description from "when the previous
payment was made" to indicate it is the Ripple Epoch timestamp when the previous
payment was due; ensure the comment still mentions the numeric Ripple Epoch
format and optional status to match the field declaration
PreviousPaymentDueDate?: number.
🧹 Nitpick comments (3)
packages/xrpl/src/Wallet/counterpartySigner.ts (1)
176-199: Consider edge case: duplicate signers across transactions.The
validateLoanSetTransactionEquivalencefunction ensures all transactions are equivalent except for theirCounterpartySignature.Signers. However,getTransactionWithAllLoanSetCounterpartySignersusesflatMapto combine all signers without checking for duplicates.If the same signer account signs multiple input transactions, the combined result would contain duplicate entries, which could cause issues during submission.
♻️ Consider deduplicating signers by Account
function getTransactionWithAllLoanSetCounterpartySigners( transactions: LoanSet[], ): LoanSet { // Signers must be sorted in the combined transaction - See compareSigners' documentation for more details - const sortedSigners: Signer[] = transactions + const allSigners = transactions .flatMap((tx) => tx.CounterpartySignature?.Signers ?? []) + + // Deduplicate by Account + const uniqueSigners = Array.from( + new Map(allSigners.map((s) => [s.Signer.Account, s])).values(), + ) + + const sortedSigners: Signer[] = uniqueSigners .sort((signer1, signer2) => compareSigners(signer1.Signer, signer2.Signer))packages/xrpl/test/wallet/counterpartySigner.test.ts (2)
1-1: Remove outdated TODO comment.This comment appears to be a development note that is no longer needed since both tests are now implemented.
Suggested fix
-// Add one test for single signing and one test for multi-signing - import { assert } from 'chai'
14-14: Typo:singedLoanSetshould besignedLoanSet.This typo appears in both test cases (lines 14 and 88).
Suggested fix for the single sign test
- const singedLoanSet = { + const signedLoanSet = {And update all references in this test case accordingly.
shawnxie999
left a comment
shawnxie999
left a comment
There was a problem hiding this comment.
The Number serialization looks good
Patel-Raj11
dismissed stale reviews from ckeshava and shawnxie999
via
fe16a34
achowdhry-ripple
left a comment
achowdhry-ripple
left a comment
There was a problem hiding this comment.
code+syntax lgtm, approving to not block release -- am less familiar with the context on the serialization changes but did not see an issue
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/ripple-binary-codec/test/st-number.test.ts`:
- Around line 87-97: Two test cases use duplicate names ('-ve normal value' and
'+ve normal value') which duplicate earlier tests; update the it(...)
descriptions to unique, descriptive names to disambiguate failures. Locate the
it blocks that call STNumber.from(...) and sn.toJSON() and rename their first
argument strings (for example include "string input" or "large value" context)
so each it(...) label is unique and clearly references STNumber.from and toJSON
behavior.
🧹 Nitpick comments (1)
packages/ripple-binary-codec/src/types/st-number.ts (1)
114-121: Shrink loop appears to be unreachable dead code.The initial mantissa overflow check at lines 98-101 rejects any
m > MAX_MANTISSAbefore reaching this loop. The growth loop (lines 108-112) cannot producem > MAX_MANTISSAsince it stops whenm >= MIN_MANTISSA, and the maximum value after growth isMIN_MANTISSA * 9 < MAX_MANTISSA.This code appears to be defensive but will never execute. Consider removing it or adding a comment explaining its purpose.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/ripple-binary-codec/src/types/st-number.ts`:
- Around line 141-143: Rounding can push m past MAX_INT64 (e.g., m == MAX_INT64
and lastDigit >= 5); after the current increment (m += BigInt(1)) add a
post-rounding shrink check that mirrors the pre-rounding MAX_INT64 handling: if
m > MAX_INT64 then repeatedly shrink the mantissa (divide/round as your existing
shrink logic does) and increment the exponent until m <= MAX_INT64, updating any
flags used for writeInt64BE serialization; ensure this uses the same shrink
routine used earlier so writeInt64BE never receives a value > MAX_INT64.
🧹 Nitpick comments (1)
packages/ripple-binary-codec/test/st-number.test.ts (1)
177-181: Consider adding a test for rounding overflow at MAX_INT64 boundary.The test suite covers rounding behavior but doesn't include a case where rounding could push the mantissa exactly to MAX_INT64 + 1. Given the potential bug in
normalize()where rounding can exceed MAX_INT64, adding a targeted test would help catch regressions.🧪 Suggested test case
it('handles rounding at MAX_INT64 boundary', () => { // Value that after shrinking lands exactly at MAX_INT64, with lastDigit >= 5 // This tests that rounding doesn't cause int64 overflow const value = '92233720368547758075' // 9223372036854775807.5 * 10 const sn = STNumber.from(value) // Verify it doesn't throw and produces valid output expect(sn.toJSON()).toBeDefined() })
4 participants
High Level Overview of Change
Recent Number type refactor in rippled changed the following:
This PR implements above two changes and fixes toJSON (string representation) to match with rippled's behaviour.
Additional changes in PR:
signLoanSetByCounterpartyandcombineLoanSetCounterpartySignershelper functions.Context of Change
Type of Change
Did you update HISTORY.md?
Test Plan
Added unit tests that takes expected value from standalone rippled instance.