Upgrade to latest version of Alloy and port Anvil tests

[zerosnacks]

Motivation

Builds on top of #7619
Closes #7449

Solution

Upgrades Foundry to latest version of Alloy

Updates the following examples to use Alloy

• abi.rs
• anvil.rs
• anvil_api.rs
• api.rs
• fork.rs
• ganache.rs
• gas.rs
• genesis.rs
• geth.rs
• ipc.rs
• logs.rs
• optimism.rs
• otterscan.rs
• proof.rs
• pubsub.rs
• revert.rs
• sign.rs
• state.rs
• traces.rs
• transaction.rs
• txpool.rs
• utils.rs
• wsapi.rs

Breaking changes:

• Remove special case handling of Polygon and Polygon Mumbai EIP-1559 fees handling of GasOracle middleware

Notes:

• The final migration of cast bind and forge bind is planned to be handled in a standalone ticket given its possible complexity and the diff has already grown massively

• Given that the port of Alloy has largely already occurred the odd cases of failing tests are largely descriptive of current issues (and flagged as such), not new issues introduced by this ticket.

• Few tests have been migrated but fail due to issues:

1. [Bug] watch_pending_transaction hangs for non-pending transactions  alloy-rs/alloy#389
   Tests failing due to test_fork_snapshotting_blocks, test_fork_timestamp, test_fork_reset_moonbeam, can_call_ots_get_transaction_error, can_replace_transaction.

2. RpcError in watch_full_pending_transactions

ErrorPayload { code: -32602, message: "invalid type: boolean `true`, expected
// unit", data: None } originating from watch_full_pending_transactions

3. Test failing: can_stream_pending_transactions: Pubsub channel_size issue in test_sub_new_heads_fast.
4. Optimism test_deposits_not_supported_if_optimism_disabled, likely the other Optimism tests aren't working as expected
5. Test failing: can_get_block_number_ipc and test_sub_new_heads_ipc fail on Windows

[zerosnacks]

@yash-atreya I've marked this as ready for review now that all tests are running (w/ exception of a few ignored tests, document reasons). I think it is best if the final migration of cast bind and forge bind is handled in a standalone ticket given its possible complexity and the diff is already massive.

[mattsse]

nice,

a few more nits and suggestions

let's convert all for those

http_provider(&handle.http_endpoint());

to handle.http_provider()

same for ws and ipc

[mattsse]

for this,

maybe the issue is here:

foundry/crates/common/src/provider/mod.rs

Lines 116 to 117 in 61bec81

	if let Ok(path) = resolve_path(path) {
	Url::parse(&format!("file://{}", path.display()))

I don't think this will work for windows
I assume this ends up here:

foundry/crates/common/src/provider/runtime_transport.rs

Lines 199 to 200 in 61bec81

	let ipc =
	ipc_connector.into_service().await.map_err(RuntimeTransportError::TransportError)?;

can we include the path in the error message here and check which path gets used here

[zerosnacks]

Got this error:

Transport(Custom(TransportErrorTest(Transport(Custom(Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." })), "file:///pipe/anvil-ipc-7861286456766970431", "\\\\.\\pipe\\anvil-ipc-7861286456766970431")))

The conversion appears to be correct (format: error, url, path), expected format is: \\.\pipe\reth_engine_api.ipc after escaping.

Attempted to replace it with the approach defined in this test in Alloy by using a tempfile: https://github.com/alloy-rs/alloy/blob/4d77029ba61284a6b4185f46581b4d9bce34f5fd/crates/rpc-client/tests/it/ipc.rs#L5

I noticed that Alloy currently only runs CI tests against latest Ubuntu making it likely that this is an area of the codebase not fully tested yet.

Going to hop onto my Windows machine and see if I can debug it there.

[zerosnacks]

I've been getting conflicting reports

I was able to replicate it locally on my Windows machine with the Alloy repo but that could be related to other issues

But when running Alloy on Windows targets in the CI it does not throw: https://github.com/zerosnacks/alloy/actions/runs/8848697130

I think it is most likely it is indeed related to some sort of formatting or handling on Foundry's side

[mattsse]

this could be an issue for the windows ipc

[mattsse]

I'm okay with disabling ipc tests on windows for now, and fix separately on alloy or in a follow up once we found it

but i really want more context (the path) included in this error, because this is useless:

thread 'ipc::can_get_block_number_ipc' panicked at crates\anvil\tests\it\ipc.rs:31:49:
called Result::unwrap() on an Err value: Transport(Custom(TransportError(Transport(Custom(Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." })))))

this needs to happen in alloy though, do we know where this is thrown?

[zerosnacks]

I'm okay with disabling ipc tests on windows for now, and fix separately on alloy or in a follow up once we found it

but i really want more context (the path) included in this error, because this is useless:

thread 'ipc::can_get_block_number_ipc' panicked at crates\anvil\tests\it\ipc.rs:31:49:
called Result::unwrap() on an Err value: Transport(Custom(TransportError(Transport(Custom(Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." })))))

this needs to happen in alloy though, do we know where this is thrown?

I agree, lets not make this a blocker and handle this in a follow up.

I've added some extra information to the TransportError in Foundry.

Some places I found suspicious:

casting to ok()

foundry/crates/anvil/src/lib.rs

Line 324 in d21c3e7

ProviderBuilder::new(&self.config.get_ipc_path()?).build().ok()

Tests for the existence of the file, not something we do in the current test. However when I changed it to use Alloy's NamedTempFile of the example it didn't work.

https://github.com/alloy-rs/alloy/blob/bbef8de3fd203bf6feb26dc619f42b2bb2ecd4e3/crates/rpc-client/src/builtin.rs#L147-L162

And as previously highlighted

foundry/crates/common/src/provider/mod.rs

Lines 113 to 117 in 5f801b4

	if let Ok(path) = resolve_path(path) {
	Url::parse(&format!("file://{}", path.display()))
	} else {
	Err(err)
	}

[mattsse]

gg

let's add a windows target to alloy CI and ensure IPC works cross platform

[zerosnacks]

gg

let's add a windows target to alloy CI and ensure IPC works cross platform

Opened a draft PR here: alloy-rs/alloy#642

I previously made a mistake when I was testing it earlier against the CI (mistakingly had set runs-on to ubuntu-latest, not {{ matrix.os }} therefore running on ubuntu, not windows). The PR handles this correctly now and shows build failures / test failures for various reasons which I'll address in that PR.