transaction confirmation workflow issue with Ganache

[davidmurdoch]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Bringing issue #2940 back to life here.

The [email protected] WebsocketProvider subscribes to newHeads after sending the transaction, which means web3 may miss the emitted newHeads notification. While it is unlikely for this race condition to be a problem on mainnet, or even test nets, it is pretty much guaranteed to be a problem when testing against Ganache v7.0.0 (currently available as a beta).

It can be a tricky race condition to reproduce as Ganache v7 is very fast for simple transactions; the immediate call to eth_getTransactionReceipt will likely return the receipt, so Web3 won't need to subscribe to newHeads. However, if the transaction sent to Ganache is sufficiently complex eth_getTransactionReceipt may return null, in which case Web3 will fall back to subscribing to newHeads. The problem is that it is possible for the newHeads subscription to arrive too late, as by the time the request is received by Ganache the block header has already been saved (and the newHeads message event won't ever be sent again).

(There is a similar race condition issue for the HttpProvider, but I don't think there is a good way of solving it on Web3's side, so we'll work on a way of dealing with this on the Ganache side)

Expected Behavior

.

Steps to Reproduce

.

Web3.js Version

1.6.1

Environment

No response

Anything Else?

No response

[davidmurdoch]

/cc @MicaiahReid

[jdevcs]

@davidmurdoch Thanks for sharing this info.

[davidmurdoch]

Quick update on our end! We switched Ganache v7.0.0's default "instamine" mode to match that of Ganache v6, so while the issue is technically there, web3 should work as usual in Ganache's default mode. You can reproduce the race condition by setting Ganache's instamine mode to "strict": ganache --miner.instamine strict. This will cause Ganache to return a transaction's hash before including the transaction in a block.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[davidmurdoch]

Bad robot

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[davidmurdoch]

Bad robot

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[davidmurdoch]

Bad robot.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[davidmurdoch]

Can we reopen this until we figure out if it is still a problem?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[Ajemark]

I'm having same issues

[mconnelly8]

6/12 - keep

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.