chore: add reproducible example of mocha missing async warning#7726
chore: add reproducible example of mocha missing async warning#7726
Conversation
|
hardhatTotal size of the bundle: List of dependencies (sorted by size) |
|
After further investigation, I have found that this issue appears to be due to the garbage collector cleaning up the in-use The local variable on line 179 does appear to serve its intended purpose according to the comment above it, however when the handler chain is run on line 188, inside the chains delayed execution is where the strange error is being thrown. Removing the local variable on line 179 or changing line 188 to invoke |
c14f4ff to
91f07ce
Compare
Adds another example project under v-next to allow replicating the issue.
91f07ce to
6009caf
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|

This fix for #7722 is still in the investigation stage. The issue is that a missing async await against our mocha assertions can lead to an invariant error - we would prefer a clear message suggesting that an
awaitis missing.This PR adds an example project that replicates the error, to run it:
Investigation status
My current hypothesis is that the lack of an await, means that some lower layer is closed or cleaned up. When the assertion
expect(txn).to.changeEtherBalance(ethers, alice, 10)is run, the test has already completed, so the calls to the in-memory EDR network connection fail,ethersreturns null for the block number and so we get the invariant exception above (but also a passing test).My guess was that the EDR connection was giving some odd error rather than a connection closed when
etherscalledgetBlock, and was then falling back onnull. However, closing the connection leads to a connection closed error, see:https://github.com/NomicFoundation/hardhat/blob/7b335f9a64b46715b9db9082ff16bbe2cf95fc81/v-next/example-project-assertion/scripts/test-closed-connection.ts
Next steps
Resolve the mechanism that leads
ethersto return null forgetBlock. Has the underlying connection been cleaned up with the completion of the test or is it some other reason? Setting up debugging is my next move.