GlobalState in clientside return nil if Table is large.

[renzuzu]

as instructed by bubble to produce repros here.

this issue cannot be reproduce on any existing Globalstate that already have a value. ( as trying to use the command in client side its only returned the old value , this is probably an issue too)

i can only reproduce with New GlobalState

Server:

RegisterCommand('fillgs', function()
	local stat = GlobalState.TEST or {} -- TEST is new
	for i = 1, 10000 do -- 10k to replicate a large table
		table.insert(stat,{
			data = 100000,
			data2 = 100000,
			data3 = 10000,
			data4 = 1000000,
			data5 = 1000000,
			data6 = 10000000,
			data7 = 10000000,
			data8 = 1000000,
		})
	end
	GlobalState.TEST = stat
end)

Server: to see the globalstate haves a data in server

RegisterCommand('vehiclestat', function() -- to see the globalstate have a data in server
	local stat = GlobalState.TEST
	for k,v in pairs(GlobalState.TEST) do
		print(k,v)
		--stat[k] = nil
	end
	GlobalState.TEST = stat
end)

Client:

RegisterCommand('vehiclestat2', function()
	for k,v in pairs(GlobalState.TEST) do
		print(k,v)
	end
end)

The Client Returned Nil value and produce and error.

i tought this is a default behavior of Oneysnc Globalstate. to prevent client receiving a large data sent from server.
but as i asked bubble, he said this could be a bug and need a repro.

im currently using Canary version of client and server artifact version 6183

[renzuzu]

today i did the same repro steps.

this seems fixed, im not sure which commits from bubble fix this.
i even tried 20k loops and its still available in client.

Great as always dbub.

[blattersturm]

... silly thing is nothing even changed in this regard... 😕

[renzuzu]

what? i tought you update something, this issue is existing even last year probably 1.2 years ago when i start implementing global statebags, i always tought that this is a default behavior of this feature thats why i didnt bother asking, when i message you just few days ago, is just to confirm if its really a default behavior or a bug.

i remember doing this fix to not save vehicle properties data to avoid large datas.
renzuzu/renzu_garage@9f24780
which is a referenced of this commit
renzuzu/renzu_garage@5d9da7c
commit date is : Nov 1, 2021

i even tested 40k loops now

its acting different now ,it dont throws any errors even with newly restarted (the globalstate is restored from KVP)
70k loops

the last time before i post this issue , i only tested with 10k loops and its already thrown error on client

i will still investigate, probably its causing if server is up for a long time.

[blattersturm]

what? i tought you update something

Nope, nothing was 'updated' in this regard. That's why this is puzzling.

[AvarianKnight]

Could this be related to this pr from a while ago?

[renzuzu]

i have tested again, different server but same artifact version, same client version.

it did throw error on 840 datas. (on client)

each data have this as exact

[script:renzu_mechani] XWX 095	table: 0000022F16399C80 <-- main table ( indexname , data value )
--each table contains this value
[script:renzu_mechani] engine_fuelinjector	100  <-- (index name, value)
[script:renzu_mechani] transmition_clutch	100
[script:renzu_mechani] engine_crankshaft	100
[script:renzu_mechani] oem_brakes	100
[script:renzu_mechani] oem_suspension	100
[script:renzu_mechani] engine_valves	100
[script:renzu_mechani] oem_gearbox	100
[script:renzu_mechani] engine_connectingrods	100
[script:renzu_mechani] engine_sparkplug	100
[script:renzu_mechani] engine_oil	100
[script:renzu_mechani] engine_airfilter	100
[script:renzu_mechani] engine_gasket	100
[script:renzu_mechani] engine_camshaft	100
[script:renzu_mechani] engine_pistons	100
[script:renzu_mechani] engine_block	100
[script:renzu_mechani] engine_flywheel	100

so 840 datas in table. main table size contains almost the same in the repro steps.

it seems the statebaghandler in client not receiving also.

Server up time is 17Days. (dedicated server ) and 2 days uptime Fivem server

this are not happening in my localhost (1 player only me)
even with 70k loops as above sample it didnt throw any error ,,

So this is really weird now.

i even tried the repro steps above now in the current server
to produce 10k loops
it did throw an error too in client when doing

for k,v in pairs(GlobalState.TEST3) do
    print(k,v)
end

hoping for a fix 🙏
i could do something as a workaround on my resource, but globalstate is really awsome feature. :D

[blattersturm]

hoping for a fix 🙏

Without reproduction steps that we actually can perform ourselves this is still unlikely though. 😕 We don't have access to your 'current server' for example, so.. eh.

[gottfriedleibniz]

One related issue is that SendKeyValue does not sanitize/handle WriteBits failing, i.e. the payload exceeding 131072 bytes.

[Felipellira]

I am having the same issue, actually, the code works perfectly on my working machine, but in my server dont