Matt Solomon
Matt Solomon
Sounds good, will move my thoughts there now
@mattsse I don't think so because ` forge test --mp test/libraries/SafeCall.t.sol` also passes It seems likely the issue is actually related to library deployments and linking: https://github.com/ethereum-optimism/optimism/pull/11426#issuecomment-2278508861. Once I remove...
@mattsse I updated my above comment, but have confirmed the cause of the bug was library linking: once we remove all public methods from libs the issue goes away
@PatrickAlphaC I think you were planning to work on this so I assigned it to you, if that changes lmk and I can unassign
Ah yep you are right. So I think we should both: - Change the default API endpoint / default API key based on the chain ID of the RPC URL...
Just noting that we're now tracking that confirmations suggestion in https://github.com/foundry-rs/foundry/issues/4748 (thanks for creating the issue!)
I think there's two things here that would be useful: 1. Below a trace, showing the decoded state diffs for the full transaction. For forge test it'd be the state...
Perhaps we close this one and create a new issue to track a decoded state diff similar to what tenderly does? Not sure if this is tracked anywhere else offhand...
Does this happen (i.e. the test erroneously passes) if the reason the test contract reverts is due to a solidity panic like overflow or divide by zero? I don't see...
Got it, makes sense! I do still think we should verify the below, to make sure users can't have tests that are passing when you'd normally expect them to fail...