I ran into a tricky bug where the combination of opening a websocket and calling fetch at about the same time
caused the fetch call to be 'stuck', i.e. it didn't do anything.

After some trail and error I finally figured out it was because tjs_xhr_finalizer was called right after doing the fetch call.
At this point I was a bit out of my depth, so I asked AI to chime in (that is to say: take the explanation and proposed solution with a grain of salt).

The theory is that due to the websocket activity, garbage collection is triggered earlier/more than in the case when fetch is called on its own.
The XMLHttpRequest that is created in the Promise for fetch does not have any strong reference to it and gets cleaned up by quickjs.

I also asked it for a more minimal reproducer and a fix, which you can have a look at here.

The reproducer starts a fetch that will take some seconds to complete and then triggers garbage collection at a high frequency.
Additionally I also added a print statement in tjs_xhr_finalizer.
The behaviour I see here is the same: tjs_xhr_finalizer is called quickly after starting and the fetch call never completes.

The proposed fix is to add an activeXHRs Set with references to XMLHttpRequests that are in progress.
When I include this change, the reproducer also behave correctly (the fetch completes and tjs_xhr_finalizer is only called after completion).

I'm reasonably confident that this is indeed the root cause, but I will leave the evaluation of the solution up to you.