For a good bug report you should probably include:
- Client (production/canary) and FXServer version
- What you expected to happen
- When you used to disconnect from the server via closing the Adaptive Card being presented of in the middle of a deferral, your source for the playerConnecting event would be effectively killed once the event ended. I have not had a chance to track down which exact FXServer version caused this regression, but I do know the last one that it was working on for me was
6230 as I was developing a queue system on it.
- What actually happens
- When you disconnect from the server via closing the Adaptive Card or quit during the middle of a deferral, the source now persists even though the playerConnecting event has ended for the player…
- Category of bug (eg. client, server, weapons, peds, native)
- Reproducible steps, preferably with example script(s)
2 Likes
The ClientHolder destructor (referenced in SetResolveCallback) is never being invoked due to a circular dependency in ClientDeferral.
1 Like
… i’m fairly sure i actually checked that, but maybe it was something entirely different that i tested.
very hard to tell as of late.
1 Like
All good! Can we expect this to be fixed for a future release?
ah, I missed the fact this requires calling presentCard at least once to hit this case. makes sense.
1 Like
When can we expect a fix for this?
This might already be fixed as of fix(server/impl): presentCard reference cycle · citizenfx/fivem@d0fd41e · GitHub, however I haven’t validated this fix beyond checking if it builds correctly.
2 Likes
Awesome! Hopefully it fixes the issue. Currently what is happening is the temporary ID for the playerConnecting event never gets disposed of which is an issue for scripts that want to tell if a player is no longer connecting. Can you post a build # here when you get a chance? I’ll be able to validate the changes if it helps 
For future reference, on a GitHub commit link there’s a list of tags that contain the specified commit:
Since a tag gets made for every server build, that’s also an easy way to tell when a change was first added.
I will test today and let you know if this fixed it. Thank you!
So tested this out. 1 part was fixed by this. If you close out the adaptive card, then your ID associated to the playerConnecting event will be disposed of properly. If you close out client when connecting to the server, your ID from playerConnecting is never disposed of…
I’m unable to replicate this with a simple setup:
AddEventHandler('playerConnecting', function(f, u, c)
print('conn', source)
c.defer()
Wait(1000)
c.update('e')
c.presentCard('{}', function()
c.update('sure')
end)
Wait(100000)
c.done('nah')
end)
If I close the client while the card is opened (F8, quit), it does seem to correctly remove the client, i.e. run GetPlayerName(65542) just returns nil.
This makes me wonder if there’s anything else needed to cause this issue. 
Ahhh okay, so correction. If you leave whilst in the connecting process, it takes a good amount of time for the source from playerConnecting to be disregarded… I don’t know if this is intended or a bug.
In the above screenshot, you’ll notice that I am in a queue, then a player drops and I start connecting (deferrals.done() was called), so I am now actually connecting to the server. I then F8 quit and then what follows next is that my source from the playerConnnecting event still stays valid for a good amount of time after…
You can see this in my dumpConnecting debug call I have. The Exists? function is just this snippet of code:
print("Exists?: " .. tostring((GetPlayerName(cData.src) ~= nil)));
A good while of time later, the source is actually disposed of from the playerConnecting event. Is this expected behavior? Just seems a bit odd because when you closer the adaptive card to stop connecting during the deferral or F8 quit, the source is disposed of instantaneously…
1 Like
Ah, I see now.
This indeed might have been different in older server versions since the cancel handler was getting invoked even if the deferral was already accepted, which would also lead to an increased chance of some other errors (like ‘Not a valid client’) and I believe a potential memory leak as well. This was actually a separate fix (fix(net/http-server): unset cancel handler on response end · citizenfx/fivem@5a78dc7 · GitHub) but the issue was found during these lifetime changes.
By ‘in the connecting process’, do you mean before or after the loading screen shows? There are three technically distinct stages here:
- Downloading resources (‘Loading content manifest’ and ‘Downloaded [resource name]’)
- Initiating the server connection (‘Fetching info from server’ and ‘Connecting to server’)
- Loading the game (with the loading screen visible)
The old behavior would often lead to errors during the first stage and it might be that was because of the initial HTTP connection timing out, which makes it kind of difficult to think of a fix that’ll make the temporary client disconnect as easily as it did before these changes, as any ‘new’ keepalive signal might lead to some false positives too.
1 Like
It happens when you’re at the UI screen still and the assets are being fetched and downloaded. It would probably be classified under the first stage. I mean it’s fine currently the way it works, I just figured that when they stop connecting to the server it’d drop the old ID right away if it’s possible. Thanks for the other fix! 
Yeah, it probably did do this but that might’ve been why people had some weird errors during connecting there. I believe clients still time out eventually during this phase just that it might indeed be a minute or two.
I’ll still look into if there’s something ‘best-effort’ that can be done here like having the cancel button or the quit command directly signal the server still, so the more common use cases would still signal ‘instantly’.
1 Like