Update custom Payment to a higher number in binary codec test #2824
Conversation
WalkthroughThe changes in this pull request focus on the Changes
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
warning [email protected]: This version is no longer supported. Please see https://eslint.org/version-support for other options. (For a CapTP with native promises, see @endo/eventual-send and @endo/captp) (For a CapTP with native promises, see @endo/eventual-send and @endo/captp) (For a CapTP with native promises, see @endo/eventual-send and @endo/captp) Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
packages/ripple-binary-codec/test/signing-data-encoding.test.ts (1)
181-183: Consider reducing duplication.The custom definitions setup is identical to the previous test case. Consider extracting this into a shared helper function.
+function createCustomPaymentDefinitions(paymentType: number): XrplDefinitions { + const customPaymentDefinitions = JSON.parse(JSON.stringify(normalDefinitions)) + // custom number would need to updated in case it has been used by an existing transaction type + customPaymentDefinitions.TRANSACTION_TYPES.Payment = paymentType + return new XrplDefinitions(customPaymentDefinitions) +} it('can create single signing blobs with modified type', function () { - const customPaymentDefinitions = JSON.parse(JSON.stringify(normalDefinitions)) - // custom number would need to updated in case it has been used by an existing transaction type - customPaymentDefinitions.TRANSACTION_TYPES.Payment = 200 - const newDefs = new XrplDefinitions(customPaymentDefinitions) + const newDefs = createCustomPaymentDefinitions(200) // ... rest of the test }) it('can create multi signing blobs with custom definitions', function () { - const customPaymentDefinitions = JSON.parse(JSON.stringify(normalDefinitions)) - // custom number would need to updated in case it has been used by an existing transaction type - customPaymentDefinitions.TRANSACTION_TYPES.Payment = 200 - const newDefs = new XrplDefinitions(customPaymentDefinitions) + const newDefs = createCustomPaymentDefinitions(200) // ... rest of the test })
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
packages/ripple-binary-codec/test/signing-data-encoding.test.ts(4 hunks)
🔇 Additional comments (3)
packages/ripple-binary-codec/test/signing-data-encoding.test.ts (3)
87-87: LGTM! Hex value is correct.
The hex value 00C8 correctly represents the decimal value 200.
194-194: LGTM! Hex value is consistent.
The hex value 00C8 is consistent with the previous test case.
76-78: LGTM! Verify transaction type availability.
The change from 31 to 200 and the added comment improve maintainability. The new value should be safe from conflicts with existing transaction types.
Let's verify that 200 isn't used by any existing transaction type:
High Level Overview of Change
31 that's used in the test would be used by new transactions, causing the test to fail. We would want to use a larger number for the custom def test
Context of Change
Type of Change
Did you update HISTORY.md?
Test Plan