Client/Monorepo: Async Stack Trace Improvements

[holgerd77]

Just dropping from an old chat message I re-found so it doesn't get forgotten:

---

A bit related to the test (coverage) setup changes on CI (from the #work channel):

My local stack traces often still look like this (on async calls):

TAP version 13
# [Integration:FullEthereumService]
# should handle ETH requests
ok 1 handled GetBlockHeaders
ok 2 handled GetBlockHeaders
ok 3 handled GetBlockBodies
ok 4 handled GetBlockBodies
ok 5 handled NewBlockHashes
1
1.1
(node:23604) UnhandledPromiseRejectionWarning: TypeError: (intermediate value) is not iterable
    at Test.<anonymous> (/Users/hdrewes/Documents/DEV/EthereumJS/ethereumjs-monorepo/packages/client/test/integration/fullethereumservice.spec.ts:55:27)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:23604) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)
(node:23604) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This is pretty annoying since debugging becomes extremely hard along these kind of cases, mostly apparent in the client which is just full of async calls.

Is there any way we can improve here? I first thought about Node async stack traces support which seems to be introduced in v12 and improved in v14, but I am actually already on v14 (v14.6.0 atm), so seems this is not improving this yet (see articles on the topic like https://stackoverflow.com/questions/64829331/async-stack-traces-in-node-js-14-15-0) or do your own additional search.

Some thoughts I had what might help:

1. The link above mentions some conditions in the code which needs to be fulfilled (unbroken chain of async methods), so it might be a way to check our client code if we can improve the code especially with regards to debuggeability).
2. Haven't looked at the release notes yet, but there might have been also some improvements along the tape version switch from v4 to v5 (https://github.com/substack/tape).

[holgerd77]

While there was no reaction for 2 years on this, I find this issue still interesting to tackle. 🙂