Add .operations() and .changes() method to TransactionResultMeta#542
Add .operations() and .changes() method to TransactionResultMeta#542hakymulla wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds a public transaction_meta module with helpers to access operations and iterate ledger entry changes from TransactionResultMeta, along with new tests covering several transaction meta versions.
Changes:
- Introduce
TransactionResultMeta::operations()returning an enum ref over V0–V3 vs V4 operation meta. - Introduce
TransactionResultMeta::changes()to iterate ledger entry changes derived from tx apply processing operations. - Add Rust tests validating
operations()andchanges()behavior across meta versions.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| tests/transaction_meta.rs | Adds unit tests for TransactionResultMeta::operations() and changes() across V0/V1/V4. |
| src/transaction_meta.rs | Introduces OperationsMetaRef and implements operations() + changes() on TransactionResultMeta. |
| src/lib.rs | Exposes the new transaction_meta module publicly. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| pub fn changes(&self) -> impl Iterator<Item = &LedgerEntryChange> { | ||
| let tx_apply_processing_ledgers: Box<dyn Iterator<Item = &LedgerEntryChange>> = | ||
| match &self.tx_apply_processing { | ||
| TransactionMeta::V0(operation_meta) => { | ||
| let res = operation_meta.iter().flat_map(|op| op.changes.0.iter()); | ||
| Box::new(res) | ||
| } | ||
|
|
||
| TransactionMeta::V1(operation_meta) => { | ||
| let iter = operation_meta | ||
| .operations | ||
| .iter() | ||
| .flat_map(|op| op.changes.0.iter()); | ||
| Box::new(iter) | ||
| } |
| #[cfg(feature = "alloc")] | ||
| pub(crate) mod num128; | ||
|
|
||
| pub mod transaction_meta; |
| pub fn changes(&self) -> impl Iterator<Item = &LedgerEntryChange> { | ||
| let tx_apply_processing_ledgers: Box<dyn Iterator<Item = &LedgerEntryChange>> = | ||
| match &self.tx_apply_processing { |
| impl<'a> TransactionResultMeta { | ||
| pub fn operations(&'a self) -> OperationsMetaRef<'a> { |
| @@ -0,0 +1,256 @@ | |||
| #![cfg(feature = "alloc")] | |||
|
|
|||
| use std::vec; | |||
| let thrid_ledger_name = &ops.get(2).unwrap().changes.get(0).unwrap().name(); | ||
| assert_eq!(*thrid_ledger_name, "Updated"); |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ee6fd47b16
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
|
|
||
| pub fn changes(&self) -> impl Iterator<Item = &LedgerEntryChange> { | ||
| let tx_apply_processing_ledgers: Box<dyn Iterator<Item = &LedgerEntryChange>> = |
There was a problem hiding this comment.
In non-std feature sets this module is still compiled, but Box is only available from the std prelude here; the crate advertises supported no_std profiles with alloc or even without alloc, so cargo check --no-default-features --features alloc / --no-default-features will fail to resolve this Box (and the no-alloc profile cannot allocate a boxed iterator at all). Please either gate this API on alloc and import alloc::boxed::Box, or return a non-allocating concrete iterator/enumeration so the supported no_std configurations keep compiling.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f51dfe5fe
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let iter = operation_meta | ||
| .operations | ||
| .iter() | ||
| .flat_map(|op| op.changes.0.iter()) | ||
| .chain( |
There was a problem hiding this comment.
For V2/V3/V4 metadata, tx_changes_before is explicitly the transaction-level changes before operations are applied, but this iterator starts with operation changes and only then appends tx_changes_before. When a transaction has both before-level and operation-level ledger changes, changes() returns them as fee, operation, before, after instead of fee, before, operation, after, so consumers replaying this helper see a non-chronological ledger-change stream.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e7ed3b0b2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let iter = operation_meta | ||
| .operations | ||
| .iter() | ||
| .flat_map(|op| op.changes.0.iter()) | ||
| .chain(operation_meta.tx_changes.0.iter()); |
There was a problem hiding this comment.
When V1 metadata has both tx_changes and per-operation changes, this iterator emits the operation changes first and the transaction-level changes last, even though the V1 metadata stores tx_changes before operations (matching the older transaction-level-before-operation layout that V2 later made explicit with tx_changes_before). Consumers using changes() to replay or inspect the metadata stream in order will see V1 changes in a different order from the metadata for those transactions.
Useful? React with 👍 / 👎.
What
Add .operations() and .changes() to TransactionResultMeta that returns ref to internal operations
Why
Closes #460
Known limitations
[TODO or N/A]