-
Notifications
You must be signed in to change notification settings - Fork 677
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
feat(clarity): Improve emitted events for Clarity post-conditions #4814
base: develop
Are you sure you want to change the base?
feat(clarity): Improve emitted events for Clarity post-conditions #4814
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4814 +/- ##
===========================================
+ Coverage 19.14% 83.27% +64.12%
===========================================
Files 465 470 +5
Lines 333874 335454 +1580
Branches 0 323 +323
===========================================
+ Hits 63932 279345 +215413
+ Misses 269942 56101 -213841
- Partials 0 8 +8
... and 434 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
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.
You're on the right track with this PR. Thanks for sending it over! 🙏 Just need to add some test coverage and address a couple other nits.
@jcnelson, thanks for reviewing! This PR is ready for a second look. Here's a summary of the changes:
#4744 mentions that upstream event dispatchers should be updated as well, but it seems like they leverage the same |
@jcnelson seems like #4744 refers to this code.. If so, what would the recommended JSON output be for the receipt's |
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.
Update on event dispatcher JSON output: I've added the post_condition_status
field to the payload object. Not entirely sure of its JSON shape. @jcnelson if a different shape is desired, please let me know.
thanks @ldiego08 - can you rebase this against the develop branch? |
fb41b66
to
8323f0d
Compare
@wileyj - done! Thanks for pointing me in the right direction. With the right base branch, reviewer groups have been tagged and other workflows triggered. :) |
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.
Thanks for this contribution @ldiego08! I have some suggestions that I think would simplify the code a bit.
@@ -578,6 +591,7 @@ impl StacksChainState { | |||
post_condition_mode: &TransactionPostConditionMode, | |||
origin_account: &StacksAccount, | |||
asset_map: &AssetMap, | |||
post_condition_statuses: &mut Vec<TransactionPostConditionStatus>, |
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.
How about instead of adding this vec, we change the return value to Result<Option<TransactionPostConditionStatus>
and it returns Ok(None)
on success or else Ok(Some(failing_condition))
? I think that could simplify things.
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.
@obycode I originally tried that approach, but things got tangled up quickly. This function is passed in a callback to the Clarity VM's run_contract_call
and bubbling up the failed post-condition from here to here where the AbortedByCallback
error is created would require a more extensive and invasive refactor. That's why I resourced to a "post-condition stream" vec as a simpler solution. Also, seems like the callback is expecting other error cases? Eager to hear your thoughts as I might be missing something.
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.
Got it. I appreciate your patience; I have had some higher priority items recently. Someone will try to take a look soon and help push this forward.
|
||
#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)] | ||
pub enum TransactionPostConditionStatus { | ||
Success, |
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.
I think we can remove this case.
@@ -1614,6 +1689,42 @@ pub mod test { | |||
&TestBurnStateDB_2_05 as &dyn BurnStateDB, | |||
]; | |||
|
|||
#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)] | |||
pub enum TransactionPostConditionStatusAssert { |
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.
I think this enum is unnecessary and could be removed with some refactoring of the test code.
Description
Adds post-condition validation status to Stacks transaction receipts.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yaml
andrpc-endpoints.md
for v2 endpoints,event-dispatcher.md
for new events)clarity-benchmarking
repobitcoin-tests.yml