Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughClient error handling updated to parse and route nested JSON error payloads (including Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/xrpl/HISTORY.mdpackages/xrpl/src/client/connection.tspackages/xrpl/test/connection.test.tspackages/xrpl/test/createMockRippled.ts
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: ckeshava
Repo: XRPLF/xrpl.js PR: 2874
File: packages/xrpl/test/integration/transactions/permissionedDomain.test.ts:25-80
Timestamp: 2025-01-08T02:12:28.489Z
Learning: The rippled C++ implementation (PR #5161) includes comprehensive test coverage for PermissionedDomain (XLS-80d) error cases. The JS SDK tests focus on the happy path since the error cases are already validated at the rippled level, following the principle of not duplicating complex validation testing across SDK implementations.
Learnt from: shawnxie999
Repo: XRPLF/xrpl.js PR: 2661
File: packages/xrpl/test/integration/transactions/mptokenAuthorize.test.ts:29-118
Timestamp: 2024-12-06T19:25:15.376Z
Learning: In the XRPLF/xrpl.js TypeScript client library, when writing tests (e.g., in `packages/xrpl/test/integration/transactions/`), we generally do not need to test rippled server behaviors, because those behaviors are covered by rippled's own integration and unit tests.
📚 Learning: 2024-12-06T19:25:15.376Z
Learnt from: shawnxie999
Repo: XRPLF/xrpl.js PR: 2661
File: packages/xrpl/test/integration/transactions/mptokenAuthorize.test.ts:29-118
Timestamp: 2024-12-06T19:25:15.376Z
Learning: In the XRPLF/xrpl.js TypeScript client library, when writing tests (e.g., in `packages/xrpl/test/integration/transactions/`), we generally do not need to test rippled server behaviors, because those behaviors are covered by rippled's own integration and unit tests.
Applied to files:
packages/xrpl/test/createMockRippled.tspackages/xrpl/src/client/connection.tspackages/xrpl/test/connection.test.ts
📚 Learning: 2024-12-06T19:27:11.147Z
Learnt from: shawnxie999
Repo: XRPLF/xrpl.js PR: 2661
File: packages/xrpl/test/integration/transactions/clawback.test.ts:165-178
Timestamp: 2024-12-06T19:27:11.147Z
Learning: In the integration tests for `clawback.test.ts`, it's acceptable to use `ts-expect-error` to bypass type checking when verifying ledger entries, and no additional type safety improvements are needed.
Applied to files:
packages/xrpl/test/createMockRippled.tspackages/xrpl/test/connection.test.ts
📚 Learning: 2024-12-06T18:44:55.095Z
Learnt from: shawnxie999
Repo: XRPLF/xrpl.js PR: 2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
Applied to files:
packages/xrpl/test/connection.test.ts
📚 Learning: 2025-01-08T02:12:28.489Z
Learnt from: ckeshava
Repo: XRPLF/xrpl.js PR: 2874
File: packages/xrpl/test/integration/transactions/permissionedDomain.test.ts:25-80
Timestamp: 2025-01-08T02:12:28.489Z
Learning: The rippled C++ implementation (PR #5161) includes comprehensive test coverage for PermissionedDomain (XLS-80d) error cases. The JS SDK tests focus on the happy path since the error cases are already validated at the rippled level, following the principle of not duplicating complex validation testing across SDK implementations.
Applied to files:
packages/xrpl/test/connection.test.ts
📚 Learning: 2025-02-12T23:28:55.377Z
Learnt from: mvadari
Repo: XRPLF/xrpl.js PR: 2895
File: packages/xrpl/test/models/clawback.test.ts:0-0
Timestamp: 2025-02-12T23:28:55.377Z
Learning: The `validate` function in xrpl.js is synchronous and should be tested using `assert.doesNotThrow` rather than async assertions.
Applied to files:
packages/xrpl/test/connection.test.ts
🧬 Code graph analysis (2)
packages/xrpl/test/createMockRippled.ts (2)
packages/xrpl/src/client/connection.ts (1)
request(291-319)packages/xrpl/src/client/index.ts (1)
request(340-359)
packages/xrpl/test/connection.test.ts (3)
packages/xrpl/src/client/connection.ts (1)
request(291-319)packages/xrpl/src/client/index.ts (1)
request(340-359)packages/xrpl/src/models/methods/index.ts (1)
AccountInfoRequest(523-523)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (4)
packages/xrpl/HISTORY.md (1)
7-9: LGTM!The changelog entry accurately documents the error handling improvement and follows the existing format.
packages/xrpl/test/createMockRippled.ts (1)
24-29: LGTM!The logic correctly injects the request ID into the error value payload to support the new error handling path in connection.ts. Since this is test utility code with controlled inputs, the implementation is appropriate.
packages/xrpl/src/client/connection.ts (1)
354-354: LGTM!Good improvement to provide a fallback when
error_messageis missing, ensuring errors likeslowDowndisplay a meaningful message even whenerror_messageis not set.packages/xrpl/test/connection.test.ts (1)
1033-1050: LGTM!Good test coverage for the new
jsonInvaliderror handling path. The test properly validates that the error is correctly propagated with the expected name and message.
| if (data.type === 'error' && data.value != null) { | ||
| // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment -- needed | ||
| const parsedValue: Record<string, unknown> = JSON.parse( | ||
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | ||
| data.value as string, | ||
| ) | ||
| if (parsedValue.id != null) { | ||
| this.requestManager.reject( | ||
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | ||
| parsedValue.id as string | number, | ||
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | ||
| new Error(data.error as string), | ||
| ) | ||
| } | ||
| } |
There was a problem hiding this comment.
Wrap JSON.parse in a try-catch to handle malformed data.value.
If data.value contains invalid JSON, JSON.parse will throw an uncaught exception. While rippled should always send valid JSON, defensive error handling would prevent the client from crashing on unexpected malformed responses.
🛡️ Proposed fix
if (data.type === 'error' && data.value != null) {
- // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment -- needed
- const parsedValue: Record<string, unknown> = JSON.parse(
- // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
- data.value as string,
- )
- if (parsedValue.id != null) {
- this.requestManager.reject(
- // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
- parsedValue.id as string | number,
- // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
- new Error(data.error as string),
- )
+ try {
+ // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment -- needed
+ const parsedValue: Record<string, unknown> = JSON.parse(
+ // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
+ data.value as string,
+ )
+ if (parsedValue.id != null) {
+ this.requestManager.reject(
+ // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
+ parsedValue.id as string | number,
+ // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true
+ new Error(data.error as string),
+ )
+ }
+ } catch (error) {
+ if (error instanceof Error) {
+ this.emit('error', 'badMessage', error.message, data)
+ }
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (data.type === 'error' && data.value != null) { | |
| // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment -- needed | |
| const parsedValue: Record<string, unknown> = JSON.parse( | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| data.value as string, | |
| ) | |
| if (parsedValue.id != null) { | |
| this.requestManager.reject( | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| parsedValue.id as string | number, | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| new Error(data.error as string), | |
| ) | |
| } | |
| } | |
| if (data.type === 'error' && data.value != null) { | |
| try { | |
| // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment -- needed | |
| const parsedValue: Record<string, unknown> = JSON.parse( | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| data.value as string, | |
| ) | |
| if (parsedValue.id != null) { | |
| this.requestManager.reject( | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| parsedValue.id as string | number, | |
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Should be true | |
| new Error(data.error as string), | |
| ) | |
| } | |
| } catch (error) { | |
| if (error instanceof Error) { | |
| this.emit('error', 'badMessage', error.message, data) | |
| } | |
| } | |
| } |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/xrpl/HISTORY.md (1)
5-15:⚠️ Potential issue | 🟡 MinorChangelog entry belongs under
## Unreleased, not## 4.6.0.The new
### Fixedblock was added inside the already-released4.6.0section (tagged 2026-02-12), while the## Unreleasedsection directly above it is empty. Because this PR is still open, any code it introduces will ship in a future release, not4.6.0. Misplacing it here will cause the entry to be missed or duplicated when the next version is cut.📝 Proposed fix
## Unreleased +### Fixed +* Better error handling in the `Client` for edge case errors + ## 4.6.0 (2026-02-12) ### Added * Add `faucetProtocol` (http or https) option to `fundWallet` method. Makes `fundWallet` work with locally running faucet servers. * Add `signLoanSetByCounterparty` and `combineLoanSetCounterpartySigners` helper functions to sign and combine LoanSet transactions signed by the counterparty. * Add newly added fields to `Loan`, `LoanBroker` and `Vault` ledger objects and lending protocol related transaction types. -### Fixed -* Better error handling in the `Client` for edge case errors - ## 4.5.0 (2025-12-16)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/xrpl/HISTORY.md` around lines 5 - 15, Move the misplaced changelog entry "Better error handling in the `Client` for edge case errors" from the released section `## 4.6.0 (2026-02-12)` into the `## Unreleased` section: locate the `### Fixed` block currently under `## 4.6.0 (2026-02-12)` in HISTORY.md and cut that bullet (or the entire `### Fixed` subsection if it's only the one entry) and paste it under the `## Unreleased` header, preserving the `### Fixed` heading if needed so the entry appears in the next release notes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@packages/xrpl/HISTORY.md`:
- Around line 5-15: Move the misplaced changelog entry "Better error handling in
the `Client` for edge case errors" from the released section `## 4.6.0
(2026-02-12)` into the `## Unreleased` section: locate the `### Fixed` block
currently under `## 4.6.0 (2026-02-12)` in HISTORY.md and cut that bullet (or
the entire `### Fixed` subsection if it's only the one entry) and paste it under
the `## Unreleased` header, preserving the `### Fixed` heading if needed so the
entry appears in the next release notes.
High Level Overview of Change
This PR does better error handling for certain edge-case errors (such as
jsonInvalid) in responses from rippled.Context of Change
I was working on some tests for rippled (XRPLF/rippled#6206) and discovered that the xrpl.js client hangs when some errors are received.
Type of Change
Did you update HISTORY.md?
Test Plan
I wasn't able to write a good integration test for some reason but I did write a unit test and test by hand against a standalone node.