[Bug] Deferrals held by one resource die when another resource listening to playerConnecting runs its GC

[lilabyte]

Summary

Ran into this while working on a connection queue. My queue resource calls deferrals.defer() and then keeps the deferrals object around for as long as the player waits (in a cache), so it can keep calling deferrals.update() and finally deferrals.done(). That resource holds a reference the whole time, but if any other JS resource also listens to playerConnecting, even one that never calls deferrals.defer() and never touches the deferrals at all, the queue loses its deferrals as soon as that other resource's GC runs. The deferrals.update() and deferrals.done() calls still go through on the server side without any error, but the client never gets them and just sits frozen on the last message it saw. Looks like when the other resource garbage collects its own unused copy of the deferrals functions, the callbacks get released for everyone, including the resource that is still holding and using them. If the other resource also keeps a reference to the deferrals, everything works fine. Stopping the other resource makes new connections work again, no need to restart the client or the server.

Issue type

Server

Repro rate

Always

Server build version

FXServer-early-access b168 linux

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

Debian 13

CPU

No response

RAM

No response

Using txAdmin?

Yes

Hosting provider

Self-hosted

Machine type

VPS

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

Two resources, and nothing else on the server listening to playerConnecting.

deferrals-holder holds every connection for 30 seconds and updates the message every second, then lets the player in:

deferrals-holder/fxmanifest.lua

fx_version 'cerulean'
games { 'gta5' }
server_script 'server.js'

deferrals-holder/server.js

on('playerConnecting', (name, setKickReason, deferrals) => {
  const source = global.source;

  deferrals.defer();

  let elapsed = 0;
  const timer = setInterval(() => {
    elapsed += 1;

    if (elapsed < 30) {
      deferrals.update(`Holding the connection: ${elapsed}/30`);
      console.log(`[holder] update ${elapsed}/30 for source ${source}`);

      return;
    }

    clearInterval(timer);
    deferrals.done();
    console.log(`[holder] done for source ${source}`);
  }, 1000);
});

deferrals-bystander only listens to playerConnecting and doesn't use the deferrals at all. The interval just throws away some memory every 250 ms so its GC runs all the time. Setting the bystander_retain_deferrals convar to true makes it keep the deferrals in an array:

deferrals-bystander/fxmanifest.lua

fx_version 'cerulean'
games { 'gta5' }
server_script 'server.js'

deferrals-bystander/server.js

const retained = [];

on('playerConnecting', (name, setKickReason, deferrals) => {
  if (GetConvar('bystander_retain_deferrals', 'false') === 'true') {
    retained.push(deferrals);
  }

  console.log(`[bystander] saw playerConnecting for ${name}, retained ${retained.length}`);
});

setInterval(() => {
  'x'.repeat(1024 * 1024).split('');
}, 250);

The bystander only uses GetConvar, nothing that touches the connection.

1. ensure deferrals-holder and ensure deferrals-bystander.
2. Connect. The client freezes right away, usually before showing even the first Holding the connection: N/30 message, while the server console keeps printing [holder] update ... all the way to [holder] done.
3. set bystander_retain_deferrals true (no restart needed, the convar is read on every playerConnecting) and connect again. Same allocations, but now every connection goes through fine, all 30 updates show up and you get in.

Expected Behavior

A resource that only listens to playerConnecting and never calls deferrals.defer() shouldn't affect a resource that deferred the connection and is still holding the deferrals. Each resource dropping its own references to the deferrals shouldn't break them for the others, as long as some resource still holds them.

Actual Behavior

The holder keeps its deferrals referenced for the whole 30 seconds (they live in the interval closure), so they are never garbage collected on its side. Still, once the bystander, which never called deferrals.defer(), has its GC collect its unused copy of the deferrals, the holder's deferrals.update() and deferrals.done() stop reaching the client. No errors anywhere, the server thinks everything worked, and the client stays stuck. Stopping the bystander makes the next connections work again, the client doesn't need a restart. With step 3 (bystander keeps the reference) it never happens, even with the GC running all the time, so it's not about load, it's about releasing those references.

Evidence

No response

Additional Context

No response

[wolfram-cfx]

Hi, thanks this is fixed in the next patch.

[Nexxed]

This is still an issue @wolfram-cfx :)

[wolfram-cfx]

there was no patch yet.

[Gogsi]

Hello,
A fix for this issue has been implemented in November 11 patch for FiveM for GTAV Enhanced. Please try again and let us know if the issue persists. Thanks for your help!