[Bug] GTAV Enhanced: Lua server callbacks intermittently time out during client startup after September 22 patch

[kevinscheffel-max]

Summary

Since the September 22 FiveM for GTAV Enhanced update, we started seeing intermittent Lua callback timeouts across multiple completely unrelated resources during player startup/join.

The affected resources all use the common ox_lib server callback mechanism. Examples included restaurant state, job/task resume state, door state, phone settings and HUD settings.

Typical client error:

callback event '::' timed out
@ox_lib/imports/callback/client.lua

The individual server callback handlers do not appear to be hanging. During instrumentation we observed the server receiving the requests and producing the corresponding callback responses.

One important finding is that upstream ox_lib registers its pending callback state after TriggerServerEvent() has already been called.

Simplified upstream order:

TriggerServerEvent(...)
pendingCallbacks[key] = callback

We changed the order so the pending callback is registered before sending the network event:

pendingCallbacks[key] = callback
TriggerServerEvent(...)

We also added callback lifecycle instrumentation and proper timeout cleanup.

With the modified callback implementation, the issue disappeared in our test. A full join produced 224 callback requests and 224 matching client responses with no callback timeout or orphan response observed. Responses were typically received within a few dozen milliseconds.

This does not prove that the root cause is inside Cfx/FiveM. The ordering in ox_lib represents a pre-existing race-prone pattern. However, this behavior only became visible for us after the recent Enhanced update and affected several previously stable, unrelated resources simultaneously.

Our suspicion is that a timing/scheduling/network-event behavior change in Enhanced is exposing this race much more reliably than before.

We are reporting this primarily to determine whether the timing/order of client -> server -> client Lua NetEvents changed in the recent Enhanced build.

Issue type

Both / Unsure

Repro rate

Often

Server build version

2205citizen-server-implFXServer-early-access b153 linux

OS

Windows 11

CPU

AD Ryze 9 5900X

GPU

NVIDIA GeForce RTX 5070 Ti

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

G-SKILL 32GB Vengeance RGB Pro

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

No response

CPU

No response

RAM

No response

Using txAdmin?

Yes

Hosting provider

Other GSP

Machine type

None

/perf endpoint output

No response

DDoS protection

yes

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Run a FiveM for GTAV Enhanced server on the current server build.

2. Install the public ox_lib resource (tested with ox_lib 3.39.0) and a small client/server Lua resource using lib.callback.await.

3. During client startup/player load, trigger multiple server callbacks from different client resources or repeatedly invoke callbacks in a short period.

4. Keep the upstream ox_lib callback implementation unchanged, where TriggerServerEvent() occurs before pendingCallbacks[key] is assigned.

5. Join/rejoin the Enhanced server and observe the client console.

6. Intermittently, one or more callback awaits can remain unresolved until ox_lib reports:
   callback event '' timed out

7. Instrument the server callback handler. In our production reproduction, affected requests reached the server and the callback handlers returned normally.

8. Modify ox_lib so pendingCallbacks[key] is registered BEFORE TriggerServerEvent().

9. Repeat the same join/startup sequence.

10. With the reordered implementation we observed 224/224 callback responses on the client and no callback timeout in the test run.

Expected Behavior

A client-triggered Lua NetEvent should be able to receive an immediate server response without application code having to account for the response becoming observable before the calling Lua code has finished setting up its local pending state.

Existing callback implementations that were stable before the Enhanced update should continue to behave consistently unless an intentional scheduling/order change was made.

All callbacks should either receive their server response normally or exhibit the same event ordering/timing characteristics as before the regression.

Actual Behavior

After the recent Enhanced update, several unrelated resources began intermittently timing out while awaiting ox_lib server callbacks during player startup.

The failures were not isolated to a specific resource or database query.

Affected callback handlers were observed executing on the server, while the client eventually reported an ox_lib callback timeout.

Changing only the callback lifecycle/order so that the pending callback is registered before TriggerServerEvent() eliminated the observed failures in our test.

After the change, a complete startup test resulted in 224 callback sends and 224 matching receives with no callback timeout.

Evidence

We can provide:

• Client log from the affected Enhanced build
• Server log from the same test
• Original ox_lib callback implementation
• Patched callback implementation
• SEND / SERVER RECEIVE / SERVER RESPONSE / CLIENT RECEIVE instrumentation
• Example affected callbacks from multiple unrelated resources

Examples of previously affected callback categories:

• Restaurant state
• Job/task resume state
• Door state
• Phone settings
• HUD settings

After applying the callback-order workaround, measured response times were generally ~20-90 ms and no callback timeout occurred during the instrumented test.

Additional Context

We are intentionally not claiming that ox_lib itself proves a FiveM networking bug.

The upstream implementation has a potentially race-prone ordering:

1. Trigger the server NetEvent
2. Create/register the pending client callback

Our workaround reverses these operations.

The important regression for us is that this implementation had been stable in normal operation previously, while after the recent GTAV Enhanced update multiple independent resources began exhibiting callback timeouts at the same time.

This suggests that Enhanced may now deliver/process the round trip quickly enough, or schedule Lua/NetEvent execution differently enough, to expose the race.

We would like clarification on whether Lua NetEvent scheduling, delivery ordering, or server-to-client response processing changed in the recent Enhanced patch.

If required, we can provide a minimal standalone reproduction resource containing only a client callback request and matching server response.
enhanced_callback_repro_v1.0.0.zip

[wolfram-cfx]

Hi, we made adjustments to the rate limiting of the script events. It allows around 75 per second atm. Adjustable using the normal rate limiter convars. We can add a queue on the client to not send more then what is allowed by default when required.

[Gogsi]

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