Thanks for this exciting project! I have been toying with the light runner a couple times now and it is hugely impressive, yielding up to two orders of magnitude performance improvements (going from ~400s to ~5s for ~2500 tests in ~400 suites, using --runInBand). Jest's isolation is hurting us a lot, even though we don't need it.
I am experiencing an issue where the start message that is sent over a test's MessageChannel may arrive after the tests' Promise has already resolved, i.e. the finished callback has already been executed. This results in excessive status message logging, as the late start event does activate the test as "running" even though it has already finished, rendering it in the "running" state forever (and consequently generating excessive status messages as more and more tests become considered "running").
I don't know exactly why/when this happens, nor do I know what the delivery guarantees are w.r.t. MessagePort message timing vs the micro task queue. My observations are with the InBandPiscina mode and this may be relevant for this to occur, considering that Piscina would otherwise communicate over message channels itself.
Potential solutions
I see two approaches that would fix my issue:
Detect when a start message is received after the promise has resolved, then ignoring the start message entirely.
Delaying the finish notification until after the start message has been received, then notifying the status runner of both events simultaneously (possibly with a microtick between the start and end notification, if needed)
I have tested locally with approach 1 and that seems to work just fine, but option 2 results in more consistently communicating test statuses without skipping status transitions (not sure if there's any invariants in this area).
I would be happy to contribute either fix, just opening this issue for discussion.
Thanks for this exciting project! I have been toying with the light runner a couple times now and it is hugely impressive, yielding up to two orders of magnitude performance improvements (going from ~400s to ~5s for ~2500 tests in ~400 suites, using
--runInBand). Jest's isolation is hurting us a lot, even though we don't need it.I am experiencing an issue where the
startmessage that is sent over a test'sMessageChannelmay arrive after the tests' Promise has already resolved, i.e. the finished callback has already been executed. This results in excessive status message logging, as the late start event does activate the test as "running" even though it has already finished, rendering it in the "running" state forever (and consequently generating excessive status messages as more and more tests become considered "running").I don't know exactly why/when this happens, nor do I know what the delivery guarantees are w.r.t.
MessagePortmessage timing vs the micro task queue. My observations are with theInBandPiscinamode and this may be relevant for this to occur, considering that Piscina would otherwise communicate over message channels itself.Potential solutions
I see two approaches that would fix my issue:
I have tested locally with approach 1 and that seems to work just fine, but option 2 results in more consistently communicating test statuses without skipping status transitions (not sure if there's any invariants in this area).
I would be happy to contribute either fix, just opening this issue for discussion.