docs: updated GetAllCompletedTransactionsStream comment#7451
Merged
SWvheerden merged 1 commit intotari-project:developmentfrom Aug 29, 2025
Conversation
Contributor
WalkthroughAdds a new streaming RPC GetAllCompletedTransactionsStream to wallet.proto and marks the existing GetAllCompletedTransactions RPC as deprecated. Updates accompanying comments to document streaming, pagination (offset, limit≤50), and filtering via status_bitflag. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant C as Client
participant S as Wallet gRPC Server
Note over C,S: Fetch completed transactions (streaming, paginated, filtered)
C->>S: GetAllCompletedTransactionsStream(Request{offset, limit≤50, status_bitflag})
alt Results available
loop Stream pages until exhausted
S-->>C: GetCompletedTransactionsResponse{transactions[]}
end
S-->>C: Stream completed (OK)
else Error
S-->>C: Stream error (status)
end
Note over C: Client aggregates or processes streamed TransactionInfo items
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
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. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
applications/minotari_app_grpc/proto/wallet.proto (1)
1146-1165: Augment example to show constructingstatus_bitflagproperly (BigInt) and reinforce cap behaviorThis prevents clients from sending incorrect 32‑bit masks or string values.
Apply this diff:
-// ```javascript -// const call = client.getAllCompletedTransactionsStream({ -// offset: 0, -// limit: 20, -// status_bitflag: 0 -// }); +// ```javascript +// // Include COMPLETED (0) and MINED_CONFIRMED (6) +// const statusBitflag = (1n << 0n) | (1n << 6n); +// const call = client.getAllCompletedTransactionsStream({ +// offset: 0, // 0-based +// limit: 20, // server caps to 50 +// status_bitflag: statusBitflag +// });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
applications/minotari_app_grpc/proto/wallet.proto(1 hunks)
⏰ 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). (9)
- GitHub Check: test (nextnet, nextnet)
- GitHub Check: test (mainnet, stagenet)
- GitHub Check: test (testnet, esmeralda)
- GitHub Check: cargo check with stable
- GitHub Check: wasm build tests
- GitHub Check: ledger build tests
- GitHub Check: ci
- GitHub Check: Cucumber tests / Base Layer
- GitHub Check: Cucumber tests / FFI
🔇 Additional comments (1)
applications/minotari_app_grpc/proto/wallet.proto (1)
1117-1121: Document pagination andstatus_bitflagsemantics accurately
- offset: 0-based index into a descending-timestamp list of completed transactions; offsets beyond the end immediately return an empty stream (wallet_grpc_server.rs:1436–1440).
- limit: total number of transactions to fetch; the server does not cap the overall result to 50, but for streaming performance it issues database calls in chunks of up to 50 (chunk_size =
min(limit, 50)) and continues until the total requested count is reached. Alimitof 0 yields no results.- status_bitflag: a bitmask over the
TransactionStatusenum. The server treats0as “no filter” (include all statuses) and, for each bitiset instatus_bitflag, includesTransactionStatus::from_i32(i)in the query (sqlite_db.rs:1264–1269).Provide an example for clients:
// Include COMPLETED (0) and MINED_CONFIRMED (6): const statusBitflag = (1n << 0n) | (1n << 6n);[mandatory_refactors_required]
Comment on lines
+1109
to
+1116
| // Streams previously completed wallet transactions to the client. | ||
| // | ||
| // The `GetAllCompletedTransactionsStream` RPC provides a paginated, filtered stream of previously completed transactions | ||
| // from the wallet database. Unlike real-time event streaming, this RPC allows clients to retrieve historical transaction | ||
| // data using offset, limit, and optional status-based filtering. | ||
| // | ||
| // This is ideal for applications that need to display a transaction history, perform analytics, or resume from a known offset. | ||
| // |
Contributor
There was a problem hiding this comment.
🛠️ Refactor suggestion
Specify sort order and cancelled-tx inclusion to match deprecated RPC semantics
The deprecated RPC explicitly says “sorted by timestamp and paginated” and “including cancelled ones.” Please state the same here to avoid ambiguity and ensure clients implement stable pagination.
Apply this diff:
-// The `GetAllCompletedTransactionsStream` RPC provides a paginated, filtered stream of previously completed transactions
-// from the wallet database. Unlike real-time event streaming, this RPC allows clients to retrieve historical transaction
-// data using offset, limit, and optional status-based filtering.
+// The `GetAllCompletedTransactionsStream` RPC provides a paginated, filtered stream of previously completed transactions
+// from the wallet database, sorted by timestamp (descending) for stable pagination. It includes cancelled transactions
+// unless filtered out via `status_bitflag`. Unlike real-time event streaming, this RPC allows clients to retrieve
+// historical transaction data using offset, limit, and optional status-based filtering.📝 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.
Suggested change
| // Streams previously completed wallet transactions to the client. | |
| // | |
| // The `GetAllCompletedTransactionsStream` RPC provides a paginated, filtered stream of previously completed transactions | |
| // from the wallet database. Unlike real-time event streaming, this RPC allows clients to retrieve historical transaction | |
| // data using offset, limit, and optional status-based filtering. | |
| // | |
| // This is ideal for applications that need to display a transaction history, perform analytics, or resume from a known offset. | |
| // | |
| // Streams previously completed wallet transactions to the client. | |
| // | |
| // The `GetAllCompletedTransactionsStream` RPC provides a paginated, filtered stream of previously completed transactions | |
| // from the wallet database, sorted by timestamp (descending) for stable pagination. It includes cancelled transactions | |
| // unless filtered out via `status_bitflag`. Unlike real-time event streaming, this RPC allows clients to retrieve | |
| // historical transaction data using offset, limit, and optional status-based filtering. | |
| // | |
| // This is ideal for applications that need to display a transaction history, perform analytics, or resume from a known offset. | |
| // |
🤖 Prompt for AI Agents
In applications/minotari_app_grpc/proto/wallet.proto around lines 1109 to 1116,
the RPC docblock omits that results must be sorted and that cancelled
transactions are included; update the comment to state the stream is sorted by
timestamp (ascending or descending—choose and document consistently) and that it
includes cancelled transactions so pagination is stable and matches the
deprecated RPC semantics; ensure the wording explicitly mentions "sorted by
timestamp and paginated" and "including cancelled ones" to remove ambiguity.
Comment on lines
+1123
to
+1145
| // - Each message in the response stream is a `GetCompletedTransactionsResponse` containing: | ||
| // - **transaction**: A `TransactionInfo` object representing a completed wallet transaction. | ||
| // | ||
| // ### `TransactionInfo` Fields: | ||
| // - **tx_id** (uint64): Unique transaction identifier. | ||
| // - **source_address** (bytes): Sender address. | ||
| // - **dest_address** (bytes): Recipient address. | ||
| // - **status** (enum): Status of the transaction (`Completed`, `Mined`, `Cancelled`, etc.). | ||
| // - **direction** (enum): `"Inbound"` or `"Outbound"`. | ||
| // - **amount** (uint64): Transaction amount in microTari. | ||
| // - **fee** (uint64): Transaction fee in microTari. | ||
| // - **is_cancelled** (bool): Whether the transaction was cancelled. | ||
| // - **excess_sig** (bytes): Signature of the transaction kernel excess. | ||
| // - **timestamp** (uint64): UNIX timestamp of the transaction creation time. | ||
| // - **raw_payment_id** (bytes): Raw payment ID used in the transaction. | ||
| // - **user_payment_id** (bytes): User-visible payment ID, if applicable. | ||
| // - **mined_in_block_height** (uint64): Block height where the transaction was mined. Zero if not mined. | ||
| // - **input_commitments** (repeated bytes): Commitments for transaction inputs. | ||
| // - **output_commitments** (repeated bytes): Commitments for transaction outputs. | ||
| // - **payment_references_sent** (repeated bytes): Metadata references associated with sent outputs. | ||
| // - **payment_references_received** (repeated bytes): Metadata references associated with received outputs. | ||
| // - **payment_references_change** (repeated bytes): Metadata references associated with change outputs. | ||
| // |
Contributor
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use exact enum types/names in field docs for consistency
Elsewhere in this proto the examples use fully-qualified enum constants (e.g., TRANSACTION_STATUS_MINED_CONFIRMED). Align this section to reduce ambiguity across languages that serialize enums as integers.
Apply this diff:
-// - **status** (enum): Status of the transaction (`Completed`, `Mined`, `Cancelled`, etc.).
-// - **direction** (enum): `"Inbound"` or `"Outbound"`.
+// - **status** (`TransactionStatus`): e.g., `TRANSACTION_STATUS_COMPLETED`, `TRANSACTION_STATUS_MINED_CONFIRMED`.
+// - **direction** (`TransactionDirection`): `TRANSACTION_DIRECTION_INBOUND` or `TRANSACTION_DIRECTION_OUTBOUND`.📝 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.
Suggested change
| // - Each message in the response stream is a `GetCompletedTransactionsResponse` containing: | |
| // - **transaction**: A `TransactionInfo` object representing a completed wallet transaction. | |
| // | |
| // ### `TransactionInfo` Fields: | |
| // - **tx_id** (uint64): Unique transaction identifier. | |
| // - **source_address** (bytes): Sender address. | |
| // - **dest_address** (bytes): Recipient address. | |
| // - **status** (enum): Status of the transaction (`Completed`, `Mined`, `Cancelled`, etc.). | |
| // - **direction** (enum): `"Inbound"` or `"Outbound"`. | |
| // - **amount** (uint64): Transaction amount in microTari. | |
| // - **fee** (uint64): Transaction fee in microTari. | |
| // - **is_cancelled** (bool): Whether the transaction was cancelled. | |
| // - **excess_sig** (bytes): Signature of the transaction kernel excess. | |
| // - **timestamp** (uint64): UNIX timestamp of the transaction creation time. | |
| // - **raw_payment_id** (bytes): Raw payment ID used in the transaction. | |
| // - **user_payment_id** (bytes): User-visible payment ID, if applicable. | |
| // - **mined_in_block_height** (uint64): Block height where the transaction was mined. Zero if not mined. | |
| // - **input_commitments** (repeated bytes): Commitments for transaction inputs. | |
| // - **output_commitments** (repeated bytes): Commitments for transaction outputs. | |
| // - **payment_references_sent** (repeated bytes): Metadata references associated with sent outputs. | |
| // - **payment_references_received** (repeated bytes): Metadata references associated with received outputs. | |
| // - **payment_references_change** (repeated bytes): Metadata references associated with change outputs. | |
| // | |
| // ### `TransactionInfo` Fields: | |
| // - **tx_id** (uint64): Unique transaction identifier. | |
| // - **source_address** (bytes): Sender address. | |
| // - **dest_address** (bytes): Recipient address. | |
| // - **status** (`TransactionStatus`): e.g., `TRANSACTION_STATUS_COMPLETED`, `TRANSACTION_STATUS_MINED_CONFIRMED`. | |
| // - **direction** (`TransactionDirection`): `TRANSACTION_DIRECTION_INBOUND` or `TRANSACTION_DIRECTION_OUTBOUND`. | |
| // - **amount** (uint64): Transaction amount in microTari. | |
| // - **fee** (uint64): Transaction fee in microTari. | |
| // - **is_cancelled** (bool): Whether the transaction was cancelled. | |
| // - **excess_sig** (bytes): Signature of the transaction kernel excess. | |
| // - **timestamp** (uint64): UNIX timestamp of the transaction creation time. | |
| // - **raw_payment_id** (bytes): Raw payment ID used in the transaction. | |
| // - **user_payment_id** (bytes): User-visible payment ID, if applicable. | |
| // - **mined_in_block_height** (uint64): Block height where the transaction was mined. Zero if not mined. | |
| // - **input_commitments** (repeated bytes): Commitments for transaction inputs. | |
| // - **output_commitments** (repeated bytes): Commitments for transaction outputs. | |
| // - **payment_references_sent** (repeated bytes): Metadata references associated with sent outputs. | |
| // - **payment_references_received** (repeated bytes): Metadata references associated with received outputs. | |
| // - **payment_references_change** (repeated bytes): Metadata references associated with change outputs. |
🤖 Prompt for AI Agents
In applications/minotari_app_grpc/proto/wallet.proto around lines 1123–1145, the
field docs use generic enum labels like `Completed`, `Mined`,
`"Inbound"`/`"Outbound"`; update these comments to use the exact fully-qualified
enum identifiers used elsewhere (for example use
TRANSACTION_STATUS_MINED_CONFIRMED or TRANSACTION_STATUS_COMPLETED and
TRANSACTION_DIRECTION_INBOUND / TRANSACTION_DIRECTION_OUTBOUND or whatever exact
names are defined in this proto), replacing the generic names so the docs are
unambiguous across languages and match the enum definitions in this file.
Comment on lines
+1167
to
+1191
| // ### Sample JSON Streamed Response: | ||
| // ```json | ||
| // { | ||
| // "transaction": { | ||
| // "tx_id": 103248, | ||
| // "source_address": "0xabc123...", | ||
| // "dest_address": "0xdef456...", | ||
| // "status": "Completed", | ||
| // "direction": "Outbound", | ||
| // "amount": 100000000, | ||
| // "fee": 200000, | ||
| // "is_cancelled": false, | ||
| // "excess_sig": "0x...", | ||
| // "timestamp": 1670000000, | ||
| // "raw_payment_id": "0xdeadbeef...", | ||
| // "user_payment_id": "0xdeadbeef...", | ||
| // "mined_in_block_height": 202000, | ||
| // "input_commitments": ["0x...", "0x..."], | ||
| // "output_commitments": ["0x...", "0x..."], | ||
| // "payment_references_sent": ["0x...", "0x..."], | ||
| // "payment_references_received": [], | ||
| // "payment_references_change": [] | ||
| // } | ||
| // } | ||
| // ``` |
Contributor
There was a problem hiding this comment.
🛠️ Refactor suggestion
Standardize enum values in sample JSON to match defined enums
Earlier examples use TRANSACTION_STATUS_* and TRANSACTION_DIRECTION_*. Keep this consistent.
Apply this diff:
-// "status": "Completed",
-// "direction": "Outbound",
+// "status": "TRANSACTION_STATUS_COMPLETED",
+// "direction": "TRANSACTION_DIRECTION_OUTBOUND",📝 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.
Suggested change
| // ### Sample JSON Streamed Response: | |
| // ```json | |
| // { | |
| // "transaction": { | |
| // "tx_id": 103248, | |
| // "source_address": "0xabc123...", | |
| // "dest_address": "0xdef456...", | |
| // "status": "Completed", | |
| // "direction": "Outbound", | |
| // "amount": 100000000, | |
| // "fee": 200000, | |
| // "is_cancelled": false, | |
| // "excess_sig": "0x...", | |
| // "timestamp": 1670000000, | |
| // "raw_payment_id": "0xdeadbeef...", | |
| // "user_payment_id": "0xdeadbeef...", | |
| // "mined_in_block_height": 202000, | |
| // "input_commitments": ["0x...", "0x..."], | |
| // "output_commitments": ["0x...", "0x..."], | |
| // "payment_references_sent": ["0x...", "0x..."], | |
| // "payment_references_received": [], | |
| // "payment_references_change": [] | |
| // } | |
| // } | |
| // ``` | |
| // { | |
| // "transaction": { | |
| // "tx_id": 103248, | |
| // "source_address": "0xabc123...", | |
| // "dest_address": "0xdef456...", | |
| - // "status": "Completed", | |
| // "status": "TRANSACTION_STATUS_COMPLETED", | |
| // "direction": "TRANSACTION_DIRECTION_OUTBOUND", | |
| // "amount": 100000000, | |
| // "fee": 200000, | |
| // "is_cancelled": false, | |
| // "excess_sig": "0x...", | |
| // "timestamp": 1670000000, | |
| // "raw_payment_id": "0xdeadbeef...", | |
| // "user_payment_id": "0xdeadbeef...", | |
| // "mined_in_block_height": 202000, | |
| // "input_commitments": ["0x...", "0x..."], | |
| // "output_commitments": ["0x...", "0x..."], | |
| // "payment_references_sent": ["0x...", "0x..."], | |
| // "payment_references_received": [], | |
| // "payment_references_change": [] | |
| // } | |
| // } |
🤖 Prompt for AI Agents
In applications/minotari_app_grpc/proto/wallet.proto around lines 1167 to 1191,
the sample JSON uses literal enum labels ("Completed", "Outbound") that don’t
match the proto enum constants used elsewhere; update the sample JSON to use the
standardized enum identifiers (e.g., TRANSACTION_STATUS_COMPLETED and
TRANSACTION_DIRECTION_OUTBOUND or the exact enum names defined in the proto) so
all examples consistently reference the proto enum values.
SWvheerden
approved these changes
Aug 29, 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.
Description
Fleshed out the GetAllCompletedTransactionsStream gRPC method since we mention is explicitly in the release notes.
Motivation and Context
Explain the usage.
How Has This Been Tested?
It hasn't
What process can a PR reviewer use to test or verify this change?
Confirm that the instructions match what is required.
Breaking Changes
Summary by CodeRabbit