-
Notifications
You must be signed in to change notification settings - Fork 92
Use AccountTree type wrapper
#783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Mirko-von-Leipzig
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some very minor suggestions, and missing a changelog entry, but otherwise this API looks much cleaner!
| .insert(update.account_id().into(), update.final_state_commitment().into()); | ||
| .insert(update.account_id(), update.final_state_commitment()) | ||
| .expect("TODO: what should we do with this error?"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Mirko-von-Leipzig What should we do with this one? This is test code, so panicking might be fine? Otherwise I'll have to add a new variant to StoreError that is only used in tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
panic is fine 👍
|
After this comment, I wanted to run some tests pointing the client to this branch (and the corresponding branch from Haven't looked too much into it yet, but running the node on |
The issue was that I forgot to update I'll try to run the client integration tests tomorrow to see if any problems occur. |
|
I ran the client integration tests, pointing the dependencies at the corresponding branch in miden-base, but I think due to the changes in the gRPC definitions a few tests are failing. So I think this PR also needs a companion PR in miden-client, cc @igamigo. |
|
Yeah, changes shouldn't be too bad, I'll work on a PR soon. |
bobbinth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thank you!
Since 0xMiden/miden-base#1254 we can now update the Cargo.toml references and merges this PR. @Mirko-von-Leipzig could you help with this? (@PhilippGackstatter is out today).
After this, I believe @igamigo will create a PR in miden-client to make sure integration tests are working against the latest next here.
| let num_block_created_notes = self.batches().num_created_notes(); | ||
| span.set_attribute( | ||
| "block.output_notes.count", | ||
| u32::try_from(num_block_created_notes) | ||
| .expect("should have less than u32::MAX output notes"), | ||
| ); | ||
|
|
||
| let num_batch_created_notes = self | ||
| .batches() | ||
| .as_slice() | ||
| .iter() | ||
| .fold(0, |acc, batch| acc + batch.output_notes().len()); | ||
| let num_batch_created_notes = self.batches().num_created_notes(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this right? Seems like there is no difference between num_block_created_notes and num_batch_created_notes and so num_erased_notes will always be 0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah nice catch. It looks like the block variant is incorrect now.
ProposedBlock::output_note_batches should be used there it seems, though the naming is a bit confusing :)
I'll create an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
|
FYI integration tests work on the client: 0xMiden/miden-client#859 |
Companion PR to 0xMiden/miden-base#1254.