[Bug] Deferrals.done throws msgpack error

[Mathu-lmn]

Summary

Using _deferrals.done('randomstring') in a AddEventHandler("playerConnecting" throws a msgpack_unpack error.

Issue type

Server

Repro rate

Always

Server build version

92

Steps to Reproduce

Have a script that does a def.done('randomstring') and see the error in your server console

Expected Behavior

Don't error and actually throw the error in the player def card

Actual Behavior

[Rodhin]

Did you waited at least 1 tick after deferrals.defer() call before calling deferrals.done()? AFAIK you need to wait 1 tick after the defer() call, I do that and both presentCard, update and done methods work as expected for me (in nodejs at least).

[Mathu-lmn]

Yes, this is the same code that always ran just fine in Legacy

[Rodhin]

Yes it worked for me too in legacy but the documentation always said that you should wait 1 tick, when I started to migrate my code it wasn't working for me either without waiting.

https://docs.fivem.net/docs/scripting-reference/events/list/playerConnecting/

[Mathu-lmn]

I tried with adding a Wait(0) before doing the def.done('t') and it still showed this error, do you remember if you had the same error in the server console ?

[Rodhin]

Hmm, no I don't remember what was the exact error, but now I removed the wait and it still works the same so maybe this is related to the Lua SDK :\

[FabianTerhorst]

The 1 tick await is no longer needed and unrelated to this, will look into this.

[sebastiendeu]

I tested the fix provided by the CFX Team (#127) and we still have the issue on the latest server binary (https://downloads.cfx-services.net/prod/019f8a75-b0f4-7dfc-8ac6-4dce4292da4a/cfx-server_linux_x64.tar.xz)

[Mathu-lmn]

I don't have this issue now 🤔 it's fixed for me

[Gogsi]

@sebastiendeu can you provide your code? Since for some people it seems to be fixed

[sebastiendeu]

It’s this line: https://github.com/SOZ-Faut-etre-Sub/SOZ-FiveM-Server/blob/oss/resources/%5Bqb%5D/qb-core/server/events.lua#L81 (the line doesn’t match because I refactored the file for enhanced functionality, but the logic, wait, and other elements are the same).

Also, I tested it more yesterday night and it appears to be a random bug. I haven’t found the root cause yet, but sometimes it works, and after a client closes, it can break the next login or not.

[sebastiendeu]

Okay, after running more tests, I think the problem is on the client side.
In some cases, after a first successful connection, if my client crashes and I don't restart the launcher, (closing the modal and reconnecting to my server) I trigger this issue.
Even if I restart my server six times, I always end up with this error.
However, if I restart both the launcher and the server, everything works perfectly.
On the client side, I haven't been able to determine what kind of crash causes this, cause some crash don't trigger this behavior.