Numeric Dictionary Keys Shouldn't Be Converted to Strings When Sent Over the Network

At the moment, numeric dictionary keys, as well as other datatypes, automatically get converted to strings when sent from the server to the client and vice versa. This is a major issue because a lot of times specific keys will be looked for and not found since the type of the key being looked for is still a number.

Our game has a client-sided Rodux store that stores player data in a list by user ID, but a client can’t get their own data using their user ID without first converting it to a string, despite the server using number datatypes just fine. This is causing a big headache for us.

To reproduce this issue, add the following code to a server script:

local remote = game.ReplicatedStorage.RemoteFunction

local dictionary = {
	[1337] = "yeehaw";
	[69420] = "yeehaw 2";

for key,value in pairs(dictionary) do
	print("[SERVER] Key:",key,"Value:",value,"Key Type:",typeof(key))

remote.OnServerInvoke = function()
	return dictionary

And add this code to a client script:

local remote = game.ReplicatedStorage.RemoteFunction

local dictionary = remote:InvokeServer()

for key,value in pairs(dictionary) do
	print("[CLIENT] Key:",key,"Value:",value,"Key Type:",typeof(key))

You’ll also need to add a RemoteFunction to ReplicatedStorage.

The output will look similar to this:

[SERVER] Key: 69420 Value: yeehaw 2 Key Type: number
[SERVER] Key: 1337 Value: yeehaw Key Type: number

[CLIENT] Key: 1337 Value: yeehaw Key Type: string
[CLIENT] Key: 69420 Value: yeehaw 2 Key Type: string

As you can see, the key type turns from a number to a string when sent across the network.

Specifically, I’ve figured out that if a dictionary doesn’t contain a key equal to 1, it converts all of the keys to strings. If a key equal to 1 is found, it will preserve the type, but throw out any value that isn’t directly sequential to the 1 (for example, 1-3 will work, but if 2 isn’t included, 3 will also be ignored. 0 and negative numbers will never be included). This is even more wonky behavior that shouldn’t happen. Keys and values should be kept intact across the network (with functions as the exception, of course).

@tyridge77 experienced this issue with instances recently, and my team discovered this issue during development, but we’re not sure if this was a recent change or something that’s been around for a long time. For all I know, it could be intended behavior, but it’s certainly not desired. It’s a big headache for my team and should definitely be fixed.


This has already been discussed before:

Yeah, just saw that. This thread is more specifically in regards to numbers, though, and the other thread barely touches on that.

1 Like

sorry for reviving this post but i am currently encountering the exact same issues with coincidentally the exact same quirks mentioned in the original post (thankfully i caught it quickly i guess);

judging by the solution response to the post mentioned in a reply above, is this supposed to be intentional? why, like many other people asked, is this not clarified anywhere if so?

as of right now, im assuming my only choice is to manually reconfigure the keys in a table after it has been received from across a remote connection to try and combat this issue? or has there since been a resolve that hasn’t been mentioned?

my current situation means that im not necessarily bothered by the omission of values under 1, but i do rely on the type of the keys to the table being consistent… exactly what is failing to happen, as mentioned in the original post: “if keys to table are all perfectly sequenced (1,2,3 …) then they are kept as numbers, else become strings” (paraphrasing but you get my issue)