"uv__has_active_reqs(loop) failed" when using ES6 modules, namely Socket.IO and Express

[MushyShaman]

Receiving this error whilst trying to run the example from the main readme.

node: ../deps/uv/src/unix/linux.c:1091: uv__poll_io_uring: Assertion `uv__has_active_reqs(loop)' failed.
Aborted (core dumped)

Here is the minimum code to reproduce:

import 'express';
import 'socket.io';
import deasync from 'deasync';
import cp from 'child_process';
console.log(deasync(cp.exec)('ls -la'));

Looking through the other issues I have not been able to find any other reports of this error. Digging around elsewhere, this seems to be coming from some low level C area, but that is beyond me.

It only occurs with ES6 modules, using commonjs' require works fine. It also only occurs when I import both socket.io and express, commenting out either import allows the deasync call to run. Furthermore, not every module causes this. Of those I tested only these 2 cause the bug to occur, which I'd imagine has something to do with their dependencies.

But the plot thickens, if you wrap the deasync call in a setTimeout, even of 0ms, it runs fine. This of course defeats the entire purpose of deasync, but I had a sneaky suspicion this would work and to me it indicates a deeper origin of the issue within Node's execution scheduling.

Environment:

• deasync: v0.1.29
• node: v20.10.0
• OS: Ubuntu 22.04
• architecture: x86_64

I'm not really expecting a solution that will allow me to use deasync for my project but I thought I'd post this here as it appears to be indicative of a much deeper problem. Love the idea of deasync by the way!

[jardicc]

If you use deasync then all javascript in your NodeJS will stop. So e.g. if SocketIO uses heartbeat pings then your app gets infarct if deasync takes too long. :-D At the same time your app won't be able to accept requests while in deasync.

[MushyShaman]

If you use deasync then all javascript in your NodeJS will stop. So e.g. if SocketIO uses heartbeat pings then your app gets infarct if deasync takes too long. :-D At the same time your app won't be able to accept requests while in deasync.

Yes I am aware of this and whilst it does not relate to the bug I will state my use case.

1. I have another module which requires a call to an async init method to set up.
2. I would like that initialised instance to be available as an import to all other areas of my code.
3. I wrap the init call in deasync, allowing me to subsequently export the objects it creates.
4. After importing this wrapper module where required, I call the start methods on my networking modules as usual.