[TA-5118] Update Docs with Batch tx#152
Merged
GuillemGarciaDev merged 8 commits intov0.1.xfrom Jul 18, 2025
Merged
Conversation
… methods, add missing tx & ledger types
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThis update revises and expands documentation across multiple files in the XRPL Go project. It introduces new transaction and ledger entry types, clarifies and adds method signatures for transaction submission and autofill, documents new wallet and hash functions, and makes formatting and metadata improvements for better navigation and accuracy. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Wallet
participant RPCClient
participant WebSocketClient
participant XRPLNetwork
User->>Wallet: Call SignMultiBatch(tx, opts)
Wallet-->>User: Returns signed batch transaction
User->>RPCClient: Autofill(tx) / AutofillMultisigned(tx, nSigners)
RPCClient-->>User: Returns autofilled transaction
User->>RPCClient: SubmitTx(tx, opts) / SubmitTxBlob(txBlob, failHard)
RPCClient->>XRPLNetwork: Submits transaction
XRPLNetwork-->>RPCClient: Immediate submission result
RPCClient-->>User: Returns SubmitResponse
User->>RPCClient: SubmitTxAndWait(tx, opts) / SubmitTxBlobAndWait(txBlob, failHard)
RPCClient->>XRPLNetwork: Submits transaction
XRPLNetwork-->>RPCClient: Finalized transaction result
RPCClient-->>User: Returns TxResponse
User->>WebSocketClient: Autofill(tx) / AutofillMultisigned(tx, nSigners)
WebSocketClient-->>User: Returns autofilled transaction
User->>WebSocketClient: SubmitTx(tx, opts) / SubmitTxBlob(txBlob, failHard)
WebSocketClient->>XRPLNetwork: Submits transaction
XRPLNetwork-->>WebSocketClient: Immediate submission result
WebSocketClient-->>User: Returns SubmitResponse
User->>WebSocketClient: SubmitTxAndWait(tx, opts) / SubmitTxBlobAndWait(txBlob, failHard)
WebSocketClient->>XRPLNetwork: Submits transaction
XRPLNetwork-->>WebSocketClient: Finalized transaction result
WebSocketClient-->>User: Returns TxResponse
Possibly related PRs
Suggested labels
Suggested reviewers
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
CodeRabbit Configuration File (
|
GuillemGarciaDev
requested changes
Jul 17, 2025
Collaborator
GuillemGarciaDev
left a comment
GuillemGarciaDev
left a comment
There was a problem hiding this comment.
Some additional notes:
- Add
PermissionedDomainledger entry type. - On
queriessection, add v2 support column to every table of queries that are v2 versions (they have a subpackagev1)
Collaborator
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![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
♻️ Duplicate comments (2)
docs/docs/xrpl/websocket.md (1)
135-137: Same by-value issue forSubmitTxAndWaitReplicate whatever change is decided for
SubmitTx, otherwise the two overloads diverge.docs/docs/xrpl/rpc.md (1)
95-98: Duplicate of WebSocket doc issue – pointer vs valueThe RPC docs show the same by-value signature for
SubmitTx. Ensure consistency with the concrete implementation.
🧹 Nitpick comments (6)
docs/docs/xrpl/ledger-entry-types.md (1)
10-12: Add missing hyperlink forDelegateto keep list consistent
Every other entry is linked to XRPL docs. Either add the correct URL or briefly note that no official link exists; otherwise readers may assume it was accidentally omitted.- - `Delegate` + - [`Delegate`](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/delegate)docs/docs/xrpl/hash.md (1)
21-36: Consider renaming functions to reflect hashing, not signing
The verbs “SignTxBlob” / “SignTx” suggest signing, yet the description says they hash already-signed data.HashTxBlob,HashTx(orTxHash*) would communicate intent more accurately and avoid confusion with the wallet’s signing helpers.docs/docs/keypairs.md (1)
31-34: Remove sentence duplication for conciseness
Lines 31-34 repeat the “exports both algorithm getters…” phrase.-However, the library already exports both algorithm getters that satisfy the `KeypairCryptoAlg` and `NodeDerivationCryptoAlg` interfaces. They're available under the package `github.com/Peersyst/xrpl-go/pkg/crypto`, which exports both algorithm getters that satisfy the `KeypairCryptoAlg`, `NodeDerivationCryptoAlg` interfaces. +However, the library already exports both algorithm getters in `github.com/Peersyst/xrpl-go/pkg/crypto`, which satisfy the `KeypairCryptoAlg` and `NodeDerivationCryptoAlg` interfaces.docs/docs/xrpl/wallet.md (1)
54-56: Document the return values forSignMultiBatchUnlike the two preceding bullets, the description for
SignMultiBatchomits its return value(s).
If the method only mutatestxand returnserror, make that explicit; otherwise list the blob/hash tuple like the other methods. Consistency here avoids guess-work for integrators.docs/docs/xrpl/transaction.md (1)
14-58: Keep the transaction list alphabetically sorted for quick lookupThe newly inserted types (e.g.
Batch,CredentialAccept,MPTokenAuthorize) break the previous alphabetical order, making the list harder to scan. Consider re-ordering the whole section or adding an automatic ToC instead.Example fix:
- - [AMMWithdraw](.../ammwithdraw) - - [Batch](.../batch) - - [CheckCancel](.../checkcancel) + - [Batch](.../batch) + - [CheckCancel](.../checkcancel) + - [AMMWithdraw](.../ammwithdraw)The same applies to the credential and MPToken entries further down.
docs/docs/xrpl/websocket.md (1)
112-118: Minor wording & article fixes“There's also a
AutofillMultisigned” → “There's also anAutofillMultisigned”.
Also, “internall” earlier in the paragraph should be “internal” (was fixed elsewhere but slipped back in some branches).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
docs/docs/intro.md(1 hunks)docs/docs/keypairs.md(4 hunks)docs/docs/xrpl/currency.md(2 hunks)docs/docs/xrpl/hash.md(2 hunks)docs/docs/xrpl/ledger-entry-types.md(2 hunks)docs/docs/xrpl/rpc.md(2 hunks)docs/docs/xrpl/transaction.md(3 hunks)docs/docs/xrpl/wallet.md(3 hunks)docs/docs/xrpl/websocket.md(1 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In the PR #113 for xrpl-go, the initial flagging of duplicated fields (`CredentialType` and `Expiration`) in the `xrpl/transaction/credential_create.go` file was determined to be irrelevant and not an actual issue.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: The CredentialCreate struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: GuillemGarciaDev
PR: Peersyst/xrpl-go#131
File: xrpl/rpc/client.go:265-265
Timestamp: 2025-03-31T17:29:49.615Z
Learning: In the XRPL Go codebase, type assertions from maps should always use the two-return pattern (value, ok := map[key].(type)) with proper error handling to avoid potential panics.
Learnt from: banasa44
PR: Peersyst/xrpl-go#144
File: examples/delegate-set/ws/main.go:26-28
Timestamp: 2025-07-04T08:04:15.312Z
Learning: In the xrpl-go codebase, example files consistently use early returns with fmt.Println(err) and return directly in main functions for error handling, while relying on defer statements like defer client.Disconnect() for cleanup. There's no pattern of wrapping main logic in separate functions to ensure cleanup - the defer statements handle this correctly with early returns.
docs/docs/intro.md (1)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
docs/docs/xrpl/ledger-entry-types.md (5)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In the PR #113 for xrpl-go, the initial flagging of duplicated fields (`CredentialType` and `Expiration`) in the `xrpl/transaction/credential_create.go` file was determined to be irrelevant and not an actual issue.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: The CredentialCreate struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: GuillemGarciaDev
PR: Peersyst/xrpl-go#131
File: xrpl/rpc/client.go:265-265
Timestamp: 2025-03-31T17:29:49.615Z
Learning: In the XRPL Go codebase, type assertions from maps should always use the two-return pattern (value, ok := map[key].(type)) with proper error handling to avoid potential panics.
Learnt from: banasa44
PR: Peersyst/xrpl-go#144
File: examples/delegate-set/ws/main.go:26-28
Timestamp: 2025-07-04T08:04:15.312Z
Learning: In the xrpl-go codebase, example files consistently use early returns with fmt.Println(err) and return directly in main functions for error handling, while relying on defer statements like defer client.Disconnect() for cleanup. There's no pattern of wrapping main logic in separate functions to ensure cleanup - the defer statements handle this correctly with early returns.
docs/docs/keypairs.md (1)
Learnt from: GuillemGarciaDev
PR: Peersyst/xrpl-go#131
File: xrpl/rpc/client.go:265-265
Timestamp: 2025-03-31T17:29:49.615Z
Learning: In the XRPL Go codebase, type assertions from maps should always use the two-return pattern (value, ok := map[key].(type)) with proper error handling to avoid potential panics.
docs/docs/xrpl/currency.md (3)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In the PR #113 for xrpl-go, the initial flagging of duplicated fields (`CredentialType` and `Expiration`) in the `xrpl/transaction/credential_create.go` file was determined to be irrelevant and not an actual issue.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: The CredentialCreate struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
docs/docs/xrpl/wallet.md (3)
Learnt from: JordiParraCrespo
PR: Peersyst/bitcoin-light#14
File: packages/frontend/wallet/src/domain/controllers/wallet.controller.ts:126-126
Timestamp: 2025-07-09T15:07:30.143Z
Learning: In the wallet controller, there's a semantic inconsistency where the importWallet method sets isImported to false. The team prefers either renaming the method to recoverWallet for clarity, or making importWallet more flexible by allowing isImported to be passed as a parameter with true as the default for imports.
Learnt from: banasa44
PR: Peersyst/xrpl-go#144
File: examples/delegate-set/ws/main.go:26-28
Timestamp: 2025-07-04T08:04:15.312Z
Learning: In the xrpl-go codebase, example files consistently use early returns with fmt.Println(err) and return directly in main functions for error handling, while relying on defer statements like defer client.Disconnect() for cleanup. There's no pattern of wrapping main logic in separate functions to ensure cleanup - the defer statements handle this correctly with early returns.
Learnt from: GuillemGarciaDev
PR: Peersyst/xrpl-go#131
File: xrpl/rpc/client.go:265-265
Timestamp: 2025-03-31T17:29:49.615Z
Learning: In the XRPL Go codebase, type assertions from maps should always use the two-return pattern (value, ok := map[key].(type)) with proper error handling to avoid potential panics.
docs/docs/xrpl/transaction.md (8)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In the PR #113 for xrpl-go, the initial flagging of duplicated fields (`CredentialType` and `Expiration`) in the `xrpl/transaction/credential_create.go` file was determined to be irrelevant and not an actual issue.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: The CredentialCreate struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: vriveraPeersyst
PR: Peersyst/xrpl-snap#129
File: packages/site/src/domain/transaction/controller/TransactionController.ts:98-111
Timestamp: 2025-05-17T14:29:55.132Z
Learning: In the TransactionController class of the XRPL Snap project, the `...rest` parameter in the `sendIOUTransaction` method does not contain flags from callers, so directly setting `flags: PARTIAL_PAYMENT_FLAG` without merging with existing flags is appropriate.
Learnt from: banasa44
PR: Peersyst/xrpl-go#145
File: binary-codec/codec.go:0-0
Timestamp: 2025-07-07T11:40:34.738Z
Learning: XRPL batch transactions have a maximum limit of 8 transactions per batch, as defined by the XRPL protocol. This constraint eliminates practical concerns about integer overflow when converting batch length to uint32.
Learnt from: banasa44
PR: Peersyst/xrpl-go#144
File: examples/delegate-set/ws/main.go:26-28
Timestamp: 2025-07-04T08:04:15.312Z
Learning: In the xrpl-go codebase, example files consistently use early returns with fmt.Println(err) and return directly in main functions for error handling, while relying on defer statements like defer client.Disconnect() for cleanup. There's no pattern of wrapping main logic in separate functions to ensure cleanup - the defer statements handle this correctly with early returns.
Learnt from: GuillemGarciaDev
PR: Peersyst/xrpl-go#131
File: xrpl/rpc/client.go:265-265
Timestamp: 2025-03-31T17:29:49.615Z
Learning: In the XRPL Go codebase, type assertions from maps should always use the two-return pattern (value, ok := map[key].(type)) with proper error handling to avoid potential panics.
Learnt from: AgustinMJ
PR: Peersyst/near-mobile#90
File: apps/mobile/src/modules/operation/containers/operation-details/operation-details.tsx:87-87
Timestamp: 2025-03-17T11:06:38.302Z
Learning: The `transactionId` is a required field in the `Operation` type from `@shared/blockchain/wci` module, so it cannot be undefined and doesn't need null-checking.
docs/docs/xrpl/websocket.md (1)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
docs/docs/xrpl/rpc.md (2)
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: In PR #113 for xrpl-go, the `CredentialCreate` struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
Learnt from: florent-uzio
PR: Peersyst/xrpl-go#113
File: xrpl/transaction/credential_create.go:30-34
Timestamp: 2025-03-11T11:50:58.330Z
Learning: The CredentialCreate struct in xrpl/transaction/credential_create.go does not have any duplicated fields as was incorrectly flagged in a previous review comment.
🔇 Additional comments (3)
docs/docs/intro.md (1)
7-7: Wording fix LGTM
Replacing “englobes” with “covers” improves clarity and fixes the spell-check issue without altering meaning.docs/docs/xrpl/currency.md (1)
1-3: Pagination metadata looks correct
Front-matter addition aligns bidirectional navigation between keypairs ↔ currency pages.docs/docs/xrpl/websocket.md (1)
125-128: Docs match implementation – no update neededThe
SubmitTxmethod inxrpl/websocket/client.goindeed takestransaction.FlatTransactionby value (see line 261), which aligns with the examples indocs/xrpl/websocket.md. No changes to the documentation are required.If you’d like to switch the API to accept a pointer for performance reasons, update the signature in both the code (e.g.
SubmitTx(tx *transaction.FlatTransaction, …)) and the docs in tandem.
GuillemGarciaDev
approved these changes
Jul 18, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[TA-5118] Update Docs with Batch tx
Description
This PR aims to add
Batchtransaction and related methods, and add missing tx and ledger types.Type of change
Checklist:
Changes
nextandpreviousbuttons.SignMultiBatchinwalletsection, addsSignTxinhashsection.wsandrpcsubmitmethods.Notes (optional)
Summary by CodeRabbit