Stack trace of failure to encode a tuple doesn't help locate caller

[aspiers]

I have a custom hardhat task which is attempting to call a contract with a write function which takes a tuple as the second parameter. It is failing with the following stack trace (after adding Error.stackTraceLimit = 100; to hardhat.config.ts):

An unexpected error occurred:

Error: invalid BigNumber value (argument="value", value=undefined, code=INVALID_ARGUMENT, version=bignumber/5.7.0)
    at Logger.makeError (/home/adam/myproject/node_modules/@ethersproject/abi/node_modules/@ethersproject/logger/src.ts/index.ts:269:28)
    at Logger.throwError (/home/adam/myproject/node_modules/@ethersproject/abi/node_modules/@ethersproject/logger/src.ts/index.ts:281:20)
    at Logger.throwArgumentError (/home/adam/myproject/node_modules/@ethersproject/abi/node_modules/@ethersproject/logger/src.ts/index.ts:285:21)
    at Function.BigNumber.from (/home/adam/myproject/node_modules/@ethersproject/abi/node_modules/@ethersproject/bignumber/src.ts/bignumber.ts:289:23)
    at NumberCoder.encode (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/number.ts:25:27)
    at /home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/array.ts:71:19
    at Array.forEach (<anonymous>)
    at pack (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/array.ts:54:12)
    at TupleCoder.encode (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/tuple.ts:54:20)
    at /home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/array.ts:62:19
    at Array.forEach (<anonymous>)
    at pack (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/array.ts:54:12)
    at TupleCoder.encode (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/coders/tuple.ts:54:20)
    at AbiCoder.encode (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/abi-coder.ts:111:15)
    at Interface._encodeParams (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/interface.ts:323:31)
    at Interface.encodeFunctionData (/home/adam/myproject/node_modules/@ethersproject/abi/src.ts/interface.ts:378:18)
    at /home/adam/myproject/node_modules/ethers/node_modules/@ethersproject/contracts/src.ts/index.ts:228:37
    at step (/home/adam/myproject/node_modules/ethers/node_modules/@ethersproject/contracts/lib/index.js:48:23)
    at Object.next (/home/adam/myproject/node_modules/ethers/node_modules/@ethersproject/contracts/lib/index.js:29:53)
    at fulfilled (/home/adam/myproject/node_modules/ethers/node_modules/@ethersproject/contracts/lib/index.js:20:58)
    at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  reason: 'invalid BigNumber value',
  code: 'INVALID_ARGUMENT',
  argument: 'value',
  value: undefined
}

As you can see, the bottom stack frame is processTicksAndRejections from node.js, and there is nothing showing which bit of my code triggered the task which is being processed from this task queue.

In this case, it's not a big deal because the task only sends a single transaction, so I know that the error is almost certainly triggered by that. But if it wasn't obvious, this would be an unpleasant situation, and I'd have to resort to sprinkling a load of console.log statements around the code in order to narrow down to the source of the error.

So I'm wondering if there's any way Hardhat could do a better job of handling the error here, e.g. by catching the exception in the caller and logging the stack trace of the caller in addition to the stack trace of the async thread. I found an explainer of node.js's event model which seemed to suggest that this might not be possible due to how node.js works; however a different Hardhat custom task in the same project was able to give a far more helpful stack trace:

Error: Subgraph sync status: warning. The diff is ~340s
    at checkSubgraphSynced (/home/adam/myproject/lib/syncStatus.ts:37:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async SimpleTaskDefinition.action (/home/adam/myproject/tasks/dataAnalysis.ts:52:5)
    at async Environment._runTaskDefinition (/home/adam/myproject/node_modules/hardhat/src/internal/core/runtime-environment.ts:308:14)
    at async Environment.run (/home/adam/myproject/node_modules/hardhat/src/internal/core/runtime-environment.ts:156:14)
    at async main (/home/adam/myproject/node_modules/hardhat/src/internal/cli/cli.ts:272:7)

Notice how here the stack trace continues beyond processTicksAndRejections, and shows the caller of the async checkSubgraphSynced function, and all the callers beyond that, all the way up to main. This is way more helpful! So why didn't I see that in the first stack trace above, and is there some way to fix that, so that it always shows the full stack trace up to main?

Thanks!

(BTW the problem would have been lessened if the error message at the top of the stack trace

invalid BigNumber value (argument="value", value=undefined ...

was less cryptic - I have submitted ethers-io/ethers.js#3772 about that.)

[fvictorio]

Hey @aspiers. The reason this happens in one task and not in the other is that the first one is handled by ethers. The top frames in that trace gives you a hint of what's going on: ethers captures an error and creates its own thing, which sometimes hides information that comes from Hardhat.

We are aware of the issue but haven't been able to do much about it. I'm not sure if ethers v6 handles this better, hopefully it does.

[aspiers]

Alright, thanks a lot for the reply. I've reported this to ethers.js here: ethers-io/ethers.js#3985