anvil crash

[maxandron]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

1.3.0-v1.3.0 (b918f9b)

What version of Foundryup are you on?

1.3.0

What command(s) is the bug in?

No response

Operating System

None

Describe the bug

Hello,

Getting this crash in Anvil on the latest version (1.3.0 that was released two hours ago.
Updated with foundryup -i v1.3.0

Stack trace:

The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: crates/anvil/core/src/eth/transaction/mod.rs:84

This is a bug. Consider reporting it at https://github.com/foundry-rs/foundry

  ���������������������������������� BACKTRACE �����������������������������������
                                � 7 frames hidden �
   8: core::panicking::panic::h4a11c031239f36a8
      at <unknown source file>:<unknown line>
   9: core::option::unwrap_failed::h62317944fa5dc382
      at <unknown source file>:<unknown line>
  10: anvil_core::eth::transaction::transaction_request_to_typed::h45a4404abaf0ead7
      at <unknown source file>:<unknown line>
  11: anvil::eth::backend::mem::Backend::simulate::{{closure}}::{{closure}}::h5944c56c54ac2eba
      at <unknown source file>:<unknown line>
  12: tokio::runtime::task::raw::poll::h1e0bf12e03a70e19
      at <unknown source file>:<unknown line>
  13: std::sys::backtrace::__rust_begin_short_backtrace::hd09d239988dcc711
      at <unknown source file>:<unknown line>
  14: core::ops::function::FnOnce::call_once{{vtable.shim}}::h188d451722164f51
      at <unknown source file>:<unknown line>
  15: std::sys::pal::unix::thread::Thread::new::thread_start::h1822d22fde68314f
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

Unfortunately, I can't say with certainty which transaction triggered it. I will try to find an example if needed.
Though it does happen pretty consistently

[maxandron]

From a quick glance, it looks like it may be happening when the type is 4 but authorization list is not passed

    // EIP7702
    if transaction_type == Some(4) || authorization_list.is_some() { // <--- here the check passes even if authorization_list is none
        return Some(TypedTransactionRequest::EIP7702(TxEip7702 {
            nonce: nonce.unwrap_or_default(),
            max_fee_per_gas: max_fee_per_gas.unwrap_or_default(),
            max_priority_fee_per_gas: max_priority_fee_per_gas.unwrap_or_default(),
            gas_limit: gas.unwrap_or_default(),
            value: value.unwrap_or(U256::ZERO),
            input: input.into_input().unwrap_or_default(),
            // requires to
            to: to?.into_to()?,
            chain_id: 0,
            access_list: access_list.unwrap_or_default(),
            authorization_list: authorization_list.unwrap(), // <--- which causes a panic here
        }));
    }

[grandizzy]

we can unwrap or default here, @mattsse @zerosnacks wdyt?

[zerosnacks]

From the EIP7702 spec: The transaction is considered invalid if the length of authorization_list is zero.

unwrap_or_default() is preferable here but the transaction should be ultimately rejected

[zerosnacks]

Instead of unwrapping we should instead bubble up the error so it catches on

let request = transaction_request_to_typed(WithOtherFields::new(request))
                        .ok_or(BlockchainError::MissingRequiredFields)?;

as it is a required field according to the 7702 spec under normal operation

Seperately we will introduce a new RPC method to bypass this requirement in #11178

[mattsse]

this panic is unrelated to #11178

we should return an error here because an empty 7702 auth doesnt make sense