[Bug] Enhanced client runs the first tick of load-time CreateThreads BEFORE onClientResourceStart (server and Legacy do the opposite)

[Enz0Z]

Summary

On the FiveM for GTAV Enhanced client, threads created with CreateThread while a resource's scripts are loading receive their first tick before that resource's onClientResourceStart event fires (same frame, threads first). On the server the order is the opposite: onResourceStart fires right after all scripts load and before any thread ticks, and Legacy resources have relied on that same order on the client for years.

Any resource that fills a shared table (config, locales, blip lists, ...) from an onClientResourceStart handler and reads it from a thread on its first tick now reads it empty on Enhanced. In our case that broke blips and crashed load-time threads across ~20 ESX resources with no error pointing at the cause.

Verified with a standalone probe resource (attached below) that logs every step with frame number and game timer, relayed to the server console.

Issue type

Client

Repro rate

Always

Server build version

139

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

not relevant

DxDiag

not relevant

Network graph

not relevant

Platform

Docker

OS version / distribution

container image Alpine Linux 3.22 (FXServer runs on musl via ld-musl-x86_64.so.1); host Debian 12 (bookworm), kernel 6.1.0-41-amd64, Docker Engine 29.4.2

CPU

Intel Core i7-4790K (8 threads); the container has no CPU limit (cpu.max = max), all 8 threads visible

RAM

32 GB on the host; the container has no memory limit (memory.max = max)

Using txAdmin?

Yes

Hosting provider

Cloud provider (AWS, GCP, Azure, etc.)

Machine type

Dedicated

/perf endpoint output

not relevant (not a performance issue)

DDoS protection

OVH Game DDoS (provider default)

ulimit -n value (Linux only)

soft 1024 / hard 524288

Docker Compose file (Docker only)

No compose file; the container is started with `docker run` (below, no secrets involved). Image: `ghcr.io/enz0z/fivem-docker:enhanced` (Dockerfile at https://github.com/Enz0Z/fivem-docker). The image is rebuilt daily on the recommended early-access artifact, so the build under test is pinned here by its number: **b139** (image label `org.opencontainers.image.version=139`, artifact `downloads.cfx-services.net/prod/01a05860-423e-79d7-ab9c-5b3fb86640b8/cfx-server_linux_x64.tar.xz`).


docker run -d --name nosignal-test --restart=always \
  --security-opt seccomp=unconfined \
  --user "$(id -u):$(id -g)" \
  --add-host host.docker.internal:host-gateway \
  -p 0.0.0.0:30130:30130 -p 0.0.0.0:30130:30130/udp \
  -p 127.0.0.1:40130:40120 \
  -e NO_DEFAULT_CONFIG=1 -e NO_LICENSE_KEY=1 \
  -v ./config:/config -v ./txData:/txData \
  -ti ghcr.io/enz0z/fivem-docker:enhanced

Steps to Reproduce

1. Drop the standalone resource ordertest (5 small files, attached at the bottom) into resources/ and add ensure ordertest to server.cfg. It has no dependencies.
2. Start the server. The server-side order is printed in the server console at startup (lines prefixed [S]).
3. Connect with the Enhanced client. The client-side order is relayed to the server console (lines prefixed [from client N] [C]), each with frame= (GetFrameCount()) and t= (GetGameTimer()).
4. Compare the position of onResourceStart fired relative to CreateThread first tick on each side.

Expected Behavior

Same order on the client as on the server (and as on the Legacy client): onClientResourceStart for the resource fires after all of its scripts have loaded and before the first tick of any thread created during loading. So a table populated inside that handler is already filled when a load-time thread reads it on its first tick.

Server, measured (b139, same resource):

[S] #01 a_first top-level
[S] #02 a_first CreateThreadNow body
[S] #03 d_server top-level
[S] #04 onResourceStart fired, CFG.x=nil            <- event: right after loading
Started resource ordertest
[S] #05 a_first CreateThread first tick, CFG.x=nil  <- threads: ~600 ms later
[S] #06 a_first CreateThreadNow after Wait(0)
[S] #07 a_first SetTimeout(0)
[S] #08 d_server CreateThread first tick

(CFG.x is nil on the server because b_config.lua is a client script; that is expected.)

Actual Behavior

Enhanced client, measured (b139). Everything happens in the same frame (247), but every thread gets its first tick before onClientResourceStart:

[C] frame=247 #01 a_first top-level
[C] frame=247 #02 a_first CreateThreadNow body
[C] frame=247 #03 b_config top-level: CFG.x = {}
[C] frame=247 #04 c_main top-level
[C] frame=247 #05 a_first CreateThread first tick, CFG.x=table: ...   <- threads tick first
[C] frame=247 #06 a_first CreateThreadNow after Wait(0)
[C] frame=247 #07 a_first SetTimeout(0)
[C] frame=247 #08 c_main CreateThread first tick
[C] frame=247 #09 onClientResourceStart fired, CFG.x=table: ...      <- event fires AFTER them

Also observed: threads tick in creation order, all script chunks have finished loading before the first tick, and a TriggerEvent to another resource with a function callback is still executed synchronously on both sides. So the difference is purely when onClientResourceStart fires relative to the first tick.

Evidence

Real-world failures this caused on our server (ESX-based; ~20 resources share one bootstrap file that requests the config from a central resource inside onClientResourceStart, exactly the pattern above). Client console on connect:

[critical] [esx_mdt] @esx_mdt/jail/client.lua:5: attempt to index a nil value (field 'blip')
> [global chunk] (esx_mdt/jail/client.lua:5)

@esx_screens/client/main.lua:22: attempt to index a nil value (local 'rendered')
> [global chunk] (esx_screens/client/main.lua:22)

Both scripts read a config table from a CreateThread on its first tick. Other resources (shop blips) failed silently: for _, v in pairs(Config.List) do AddBlipForCoord(...) end iterated an empty table and never retried. The same resources, unchanged, work on Legacy.

The probe resource used to measure the order is attached (ordertest/, 5 files, ~60 lines). Its whole client log is relayed to the server console, so no client log collection is needed.

Additional Context

Attachment: ordertest resource

fxmanifest.lua

fx_version 'cerulean'
game 'gta5'
lua54 'yes'

shared_script 'a_first.lua'
client_scripts { 'b_config.lua', 'c_main.lua' }
server_script 'd_server.lua'

a_first.lua

-- First script of the resource (same position as a shared "imports" file).
local side = IsDuplicityVersion() and 'S' or 'C'
local seq = 0
function L(msg)
	seq = seq + 1
	local frame = side == 'C' and tostring(GetFrameCount()) or '-'
	local line = ('[%s] frame=%s t=%d #%02d %s'):format(side, frame, GetGameTimer(), seq, msg)
	print(line)
	if side == 'C' then TriggerServerEvent('ordertest:log', line) end -- relay to server console
end

L('a_first top-level')
CFG = {}
CreateThread(function()
	L('a_first CreateThread first tick, CFG.x=' .. tostring(CFG.x))
end)
Citizen.CreateThreadNow(function()
	L('a_first CreateThreadNow body')
	Wait(0)
	L('a_first CreateThreadNow after Wait(0)')
end)
SetTimeout(0, function() L('a_first SetTimeout(0)') end)
AddEventHandler(side == 'S' and 'onResourceStart' or 'onClientResourceStart', function(name)
	if name ~= GetCurrentResourceName() then return end
	L('onResourceStart fired, CFG.x=' .. tostring(CFG.x))
end)

b_config.lua

-- Same position as a consumer's config.lua: declares the table the config will fill.
L('b_config top-level: CFG.x = {}')
CFG.x = {}

c_main.lua

-- Same position as a consumer's client/main.lua.
L('c_main top-level')
CreateThread(function() L('c_main CreateThread first tick') end)

d_server.lua

L('d_server top-level')
CreateThread(function() L('d_server CreateThread first tick') end)
RegisterNetEvent('ordertest:log', function(line) print(('[from client %s] %s'):format(source, line)) end)

[Enz0Z]

Fixed in #545.