feat(`anvil`): support better debugging flows when using `anvil` programmatically via `EthApi`

[reem]

Component

Anvil

Describe the feature you would like

There are several features which would be useful to support out of the box with anvil when using it via EthApi that already have some level of support within forge:

• [ ] Ability to query for transaction exit reason/revert message given transaction hash
• [ ] Ability to get some form of stack trace from a reverted transaction given transaction hash
• [ ] Ability to programmatically access transaction traces as offered with logging and within forge
• [ ] Ability to get console.log outputs (as returned data, not logged) from a transaction given the transaction hash

Probably there are even more features available in forge that would be useful to expose here that I am not thinking of!

Additional context

Some of this data is available internally already e.g. here https://github.com/foundry-rs/foundry/blob/63c71b4f3e162c5ab7da696b865a74ba8eda80c1/anvil/src/eth/backend/executor.rs#L156-L171 but it is not forwarded to be easily accessible via EthApi

[mattsse]

thanks for this.

supportive of this, since we already have (all|most?) of the data, we need to figure out how to make it available.

Perhaps with some additional helper functions/types that are Tx + DebugInfo or something?

[reem]

Additional functions that also return debug info would work, it would be doubly nice to make this info accessible when using anvil over rpc but I also think it would still be valuable if exposed first as just methods on EthApi

[mattsse]

makes sense, perhaps the easiest way to integrate this is to adapt this

https://github.com/foundry-rs/foundry/blob/676ff13aa18da3590068489e1a32bc1808106fc6/anvil/src/eth/backend/mem/mod.rs#L1676-L1687

so it returns a TransactionInfo which is TX+additional stuff extracted from storage

[Alexintosh]

I would love to see this happen, it's a bit of a missing piece right now.

[mattsse]

@Alexintosh are you referring to this being available programmatically or via RPC?

[rickbeeloo]

Is it already possible to debug anvil transactions?

[zerosnacks]

@reem is this still relevant to your use case? If so, I think the best next step is to break this ticket up into its own actionable tickets so they can be picked up. I'm supportive of improving programmatic access to Anvil though it may be more of a design goal for Anvil-on-Reth post-1.0.

[zerosnacks]

Marking as not planned given there has been no conversation or requests since. We will take the request into consideration when we will evaluate the specification and requirements of reth-anvil. Feel free to leave a comment if you still feel strongly about this - perhaps we can re-scope it into smaller, more actionable tickets.