Description
What is the problem this feature will solve?
Test frameworks will sometimes interact with product code that performs synchronous (or even asynchronous) work, and meanwhile kicks off background asynchronous work. If said background work attempts to operate on objects after the test has completed, this throws errors that are hard to track down the source of.
When running a test suite with hundreds of tests, we will sometimes see, for example, messages from React
's setState
that it was invoked on a component that no longer exists, but the stack trace doesn't contain the code of the offending test (or even indicate which file contained the offending test).
What is the feature you are proposing to solve the problem?
It would be helpful to have an API on node:async_hooks
that will execute a <TResult>() => TResult
and monitor for any asynchronous work that is scheduled by the execution (following the async context tree). If the work has not completed by the time the function returns (or, if it returns a Promise
, by the time the Promise
has resolved), the API should throw an error identifying the async work that is still on the queue. This can then allow for the surfaced error to be ascribed to the test function that has the problem, rather than processImmediate
or processNextTick
or similar.
What alternatives have you considered?
I've considered trying to hack something together directly using the node:async_hooks
functionality, but the API documentation says to make a feature request if there is a suitable scenario.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status