Forge test tracing does not seem to respect the Etherscan or signature caches when running tests with high verbosity

[emo-eth]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (293fad7 2024-01-14T00:19:24.272194000Z)

What command(s) is the bug in?

forge test

Operating System

macOS (Apple Silicon)

Describe the bug

See #6791 for more context.

Foundry appears to keep a cache of Etherscan ABIs and OpenChain signatures (at ~/.foundry/cache/etherscan/... and ~/./foundry/cache/signatures, respectively), but running tests with high verbosity on a slow internet connection results in extremely slow test runs, presumably due to pulling Etherscan/OpenChain metadata to format the traces.

It's possible that I'm misunderstanding what these caches are meant to be used for, or the root of the slow test runs issues on slow internet.

[mattsse]

this is probably the same issue as #6791 where slow etherscan requests slow everything down.

could you run with RUST_LOG=etherscanidentifier and check the relevant etherscan settings in forge config perhaps there's a config bug resulting in wrong etherscan url

[zerosnacks]

Potentially identified a cause here: foundry-rs/block-explorers@main...zerosnacks:block-explorers:fix/cache-is-always-invalidated where the expiry is subtracted from the current timestamp, resulting in a checked underflow -> None, indicating a cache miss when it actually hit.

foundry/crates/evm/traces/src/identifier/etherscan.rs

Line 191 in 0875a83

let res = client.contract_source_code(addr).await;

calls to:

https://github.com/foundry-rs/block-explorers/blob/1845b1067b4bb85209fe23f8469047f9c346d755/src/contract.rs#L398-L420

I haven't looked at the signature cache.

I'll need to do more testing and write tests for foundry-block-explorer to confirm this is actually the case.