forge create, cast call/send returns an error message saying transaction did not go through, even though it did

[holma91]

Component

Forge, Cast

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (90617a5 2022-04-12T00:13:04.257461+00:00)

What command(s) is the bug in?

forge create, cast call, cast send

Operating System

macOS (M1)

Describe the bug

running forge create --rpc-url $my_rpc --private-key $my_pk src/Contract.sol:Contract

with this contract:

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.13;

contract Contract {
    uint256 public a;

    constructor() {
        a = 1 + 2;
    }
}

gives me this error message:

[⠆] Compiling...
Compiler run successful
Error: 
   0: Contract was not deployed

Location:
   cli/src/cmd/forge/create.rs:194

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

However if I go to my address on etherscan, the contract was deployed. I get this output from forge create around 80% of the time, and the expected "successful deployment" message 20% of the time.

If I instead run like this

RUST_LOG=ethers_providers=trace forge create --rpc-url $rpc_rinkeby --private-key $pk src/Contract.sol:Contract

this line stands out to me:

2022-04-19T15:40:36.326634Z DEBUG ethers_providers::pending_transaction: Dropped from mempool, pending tx 0xe1856bc98482d2d60b6e2def894d2241dc1314e28746662399157454437506fe

Essentially the same happens if I use cast call or cast send, for example this command:

cast call <address> "a()(uint)" --rpc-url $my_rpc

results in:

receipt not found when polling pending tx. was the transaction dropped from the mempool?

even though the message call went through. (exactly the same issue with cast send)

[onbjerg]

This is more of an ethers-rs issue since that is where we get the provider from. Out of curiosity, what RPC do you use (alchemy, infura etc), and is your internet connection spotty?

For a fix in Forge, we should consider doing what casts does and emit a warning when we think the transaction has been dropped, so the user can check for themselves:

foundry/cast/src/lib.rs

Line 600 in 92427e7

None => return Ok("receipt not found when polling pending tx. was the transaction dropped from the mempool?".to_string())

Also looping in @mattsse, maybe he has some ideas for fixing this in ethers

Edit: Ah, I see some of these are cast commands. If cast returns that message, then it basically just means that the node you are talking to has no knowledge of the transaction. This can happen if the node is out of sync, but sometimes it's just because the node has not received the transaction yet.

We should make the ContractError::ContractNotDeployed variant a bit more robust - currently, if we think the transaction was dropped from the mempool then we just assume the contract was not deployed, which might not be the case

[mattsse]

yeh this mempool related,
the core problem is that PendingTransaction can't distinguish between a tx that's temporarily unavailable or actually dropped from the mempool, depending on the node you're connecting to. But I think we made some improvements on that front some time ago, but rinkeby was always not really reliable

this is rather an issue in ether's PendingTransaction impl I believe

cc @prestwich

[prestwich]

yeah, I'm somewhat at a loss as to how to improve it. Maybe a grace period of n attempts before it assumes the tx was dropped?

[holma91]

This is more of an ethers-rs issue since that is where we get the provider from. Out of curiosity, what RPC do you use (alchemy, infura etc), and is your internet connection spotty?

For a fix in Forge, we should consider doing what casts does and emit a warning when we think the transaction has been dropped, so the user can check for themselves:

foundry/cast/src/lib.rs

Line 600 in 92427e7

None => return Ok("receipt not found when polling pending tx. was the transaction dropped from the mempool?".to_string())

Also looping in @mattsse, maybe he has some ideas for fixing this in ethers

Edit: Ah, I see some of these are cast commands. If cast returns that message, then it basically just means that the node you are talking to has no knowledge of the transaction. This can happen if the node is out of sync, but sometimes it's just because the node has not received the transaction yet.

We should make the ContractError::ContractNotDeployed variant a bit more robust - currently, if we think the transaction was dropped from the mempool then we just assume the contract was not deployed, which might not be the case

good internet connection, and have tested with different rpcs (alchemy, infura and quicknode) with the same results. Mainly on rinkeby!

[prestwich]

@mattsse @onbjerg I'm doing some research. ethers.js uses this code to wait for a transaction

https://github.com/ethers-io/ethers.js/blob/bc400c7b87b03438abb2f9874ec136dbf7b6437c/packages/providers/src.ts/base-provider.ts#L1273-L1405

I'm traveling and it might take me a bit to parse the promise spaghetti. Generally the flow of the logic looks to be scanning each incoming block for the tx or its replacement. which is just... great 😅

[mattsse]

-.-
that's one way to do it, they also check for replacements.

Maybe a grace period of n attempts before it assumes the tx was dropped?

that's probably an easier fix for us, maybe with a retry counter or something

[prestwich]

could do something like a loop querying get_transaction_count for both latest and pending? compare those numbers to see if any txns have confirmed with the expected nonce?

[onbjerg]

I think a grace period makes more sense. FWIW I've heard of multiple people having this issue on some testnets, in particular Rinkeby, so perhaps it's just a Rinkeby thing

[onbjerg]

This should have been fixed in gakonst/ethers-rs#1221, let us know if it is not!