tenderly provider ext

[siosw]

Motivation

add tenderly provider extension #2667

Solution

for now this only adds the support for the simulation but wanted to get this up for discussion

I'm a little unsure about the TenderlyLogInput deserde, is there a smarter way of implementing this that I'm missing?

I set the provider tests to be ignored since they require access to a tenderly endpoint

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

supportive,

suggesting to introduce future types for the simulate calls, like we use for ethcall and ethcallmany, this gives a nicer api with only (txrequest) as argument and then setter functions for the call future

[siosw]

supportive,

suggesting to introduce future types for the simulate calls, like we use for ethcall and ethcallmany, this gives a nicer api with only (txrequest) as argument and then setter functions for the call future

thanks for taking a look. agree it would be nicer to have the same api as eth call & reuse the type.
i stumbled onto some unexpected behaviour of EthCall, basically

let call: EthCall<Ethereum, String> = EthCall::new(provider.weak_client(), "tenderly_simulateTransaction", tx.clone()).block(block.into());
let res = call.await;

ends up calling eth_estimateGas
i think this happens whenever the method string is not equal to eth_call
is there something I'm missing here?

[siosw]

ah ok i guess it's this:

alloy/crates/provider/src/provider/eth_call/mod.rs

Line 101 in 1f157f0

if method.eq("eth_call") { caller.call(params) } else { caller.estimate_gas(params) }?;

do you think we should make ethcall support more rpc calls? or create a similar type specifically for the tenderly apit?
in any case the current ethcall impl seems confusing to me because it makes it seem like it acceps arbitrary rpc calls.

[siosw]

@mattsse i got it working with EthCall & EthCallMany but it requires some changes to the types.
there are two issues with this approach that i've been running into:

• tenderly requires an explicit block number for simulation which doesn't match the EthCall behavior
• when submitting more than one bundle to EthCallMany all bundles other than the first one are silently dropped

maybe this means we will have to implement tenderly specific future types for this? wdyt?

[mattsse]

I see,

okay after thinking about this, let's just go with all the params as args, this is easier and we dont need to change any existing code for this.