Add vm_error field for transactions in Block Replay #6575
Conversation
|
Awesome! So we can assume any time there is a non-null vm-error string something went wrong, in my case we don't really care what went wrong, but can use the presence as a general failed indicator? |
Correct, the presence of vm_error signals a runtime error |
| description: transaction id | ||
| description: transaction id | ||
| vm_error: | ||
| type: string |
There was a problem hiding this comment.
| type: string | |
| type: [string, "null"] |
| pub tip_transactions: Vec<StacksTransaction>, | ||
| pub ignore_transaction_errors: bool, |
There was a problem hiding this comment.
could you add two docstring one liners with what these two parameters do? We also started using the NakamotoBootPlan for AAC, and documenting this parameters will be useful for the rest of the team!
| }, | ||
| NakamotoBootTenure::NoSortition(boot_steps) => { | ||
| let boot_steps_len = boot_steps.len(); | ||
| match boot_steps.get_mut(boot_steps_len - 2).unwrap() { |
There was a problem hiding this comment.
just for my own understanding: why the -2 in case of NoSortition?
4 participants
Description
This patch improves the Block Replay endpoint by allowing it to returns the specific vm_error of a failed transaction.
A new test has been added and the TestRPC framework has been improved for allowing the addition of custom transactions in the tip block.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yamlandrpc-endpoints.mdfor v2 endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepobitcoin-tests.yml