feat: raise_on_revert=False kwarg for allowing failures on calls and transactions

[antazoey]

What I did

fixes: #2180
Fixes: Ape-1788

How I did it

How to verify it

Checklist

• All changes are completed
• New test cases have been added
• Documentation has been updated

[antazoey]

• make work for alls

[fubuloubu]

Overall, I think I do like raise_on_revert better for the kwarg name, as it shows the python action (e.g. raiseing an error) is tied to the EVM result (e.g. the transaction reverts)

[antazoey]

• Support ape-hardhat feat: support raise_on_revert=False for sending calls and transactions ape-hardhat#176
• Support ape-foundry feat: support raise_on_revert flag for calls and transactions ape-foundry#106

[fubuloubu]

This looks great!

One thing I am considering is what happens when partial failure(s) exist in a receipt? (Reverts but handled by upstream logic e.g. SafeTx execution)

This is probably a tracing feature (out or scope for this PR), something like ReceiptAPI.ignored_reverts -> list[ContractLogicError], but might be good to think of how they might work together before merging this

[antazoey]

but might be good to think of how they might work together before merging this

We could put all reverts in a list and have .error refer to the last one?

[antazoey]

tbd im not sure what the experience is like with partially failed txs. Is there a way using local developer networks to simulate this?

[fubuloubu]

tbd im not sure what the experience is like with partially failed txs. Is there a way using local developer networks to simulate this?

You'd need a contract that does a call to another contract, and then handle the result. In vyper you can do this with raw_call, there is no native exception handling yet. Solidity does allow exception handling with the new custom errors stuff I think using try/catch: https://docs.soliditylang.org/en/v0.8.26/control-structures.html#try-catch

[fubuloubu]

but might be good to think of how they might work together before merging this

We could put all reverts in a list and have .error refer to the last one?

I think in this scenario if it doesn't revert then .error will be None, but then separately .ignored_reverts may not be empty regardless of whether ultimately the transaction reverted or not (as an error may have been ignored earlier in the trace)

Ultimately seems best to keep these two features separate actually, since they are orthogonal (and likely dependent on the availability of tracing to get)