Data Store "stringifies" array indexes if array doesn't start from index 1, and behaves incosistently when array has missing indexes

[LightningLion58]

When trying to save an array that doesn’t have the index/key 1 defined, the array’s keys turn to strings when retrieved using GetAsync.

Reproduction Steps:
Create a new experience and enable studio access to API Services

Run the following script/line using the Command Bar:

game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):SetAsync("Key", {[2] = "a", [3] = "b"})

Now get the data back using GetAsync, also using the command bar:

print(game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):GetAsync("Key"))

You’ll find that the indexes/keys of the array are now strings instead of numbers.

---

In addition, if that array does contain the key/index 1, but the array has a missing key-value pair inside it, in some cases, only a part of the array is stored.

Reproduction Steps:
Run the following script/line using the Command Bar:

--Notice how index/key 2 is missing, watch what happens when the data is retrieved:
game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):SetAsync("Key", {[1] = "a", [3] = "b"})

Now get the data back using GetAsync, also using the command bar:

print(game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):GetAsync("Key"))

Key/Index 3 is no longer in the array, for some reason.

I tried adding a 4th key to the array with a missing 2nd key/index. For some reason, it works in that case:

game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):SetAsync("Key", {[1] = "a", [3] = "b", [4] = "c"})
print(game:GetService("DataStoreService"):GetDataStore("SomeDataStore"):GetAsync("Key"))

This behavior seems to be inconsistent. I couldn’t find any documentation on the above occurrences.

System information:

Expected behavior

I expect the array to be stored exactly like I stored it.
Which means, keys/indexes should still be numbers if index/key 1 is missing, and values shouldn’t be emitted from the array if the array has a missing key/index inside it.

[VegetationBush (FartedWayTooHard)]

The problem is that there are holes in your array, which can lead to undefined behavior. Arrays are supposed to be filled to the brim with values, meaning there shouldn’t be any holes.

If there are holes in the array, it might be treated as a dictionary. The engine also converts all non array indices to strings.

Remote events and callbacks | Documentation - Roblox Creator Hub

[noblemaxx (monkeybaby)]

It has to do with json encoding I’m pretty sure. Like @VegetationBush said, anything not starting from 1 or with holes in the indexing converts to a dictionary because the indexing data would be lost if it were stored as an array in json formatting.

For example if you tried to save {[2] = true} as an array in json, it would be [true] which doesn’t include the position. So instead, it is saved like [[“2”] = true]. (the formatting is probably off I don’t remember json too well)

As for the data loss, I’m not sure what processes cause that! My guess is that when saving arrays, it iteratively goes through each value until the first gap is reached and ignores the rest. But if the first value doesn’t exist, it counts it as a dictionary.

[oSudden (Sam)]

This isn’t a bug, this is intended, and if I am not mistaken this also happens when transferring arrays over remotes.

The reason this is intended, as @VegetationBush stated, is that breaking the indexing of an array causes issues such as the breaking of certain table manipulation functions (table.remove, table.len/#) and hence Roblox converts the array into a string index based table.

My question is why is this such an issue to you? All developers seem to get around it fine and honestly I rarely use arrays anyways since indexing in them can be a pain.

[LightningLion58]

Thank you for the reply.

@oSudden

This isn’t a bug, this is intended, and if I am not mistaken this also happens when transferring arrays over remotes

Where is this documented as intended behavior?
I reported this since I could not find a single thread mentioning this.

I’ve spent an hour trying to figure out why trying to index the array using numbers didn’t work when I clearly saved them as such.

If this isn’t a bug, then at the very least it should be documented clearly in the datastore page, and not in any other page like remote events, where there is very little chance anyone would remotely find it there.

@oSudden

The reason this is intended, as @VegetationBush stated, is that breaking the indexing of an array causes issues such as the breaking of certain table manipulation functions (table.remove, table.len/#) and hence Roblox converts the array into a string index based table.

Where is this stated?

@oSudden

My question is why is this such an issue to you? All developers seem to get around it fine and honestly I rarely use arrays anyways since indexing in them can be a pain.

This is an issue because I could not find this behavior documented anywhere in the datastores page. I’ve spent time trying to figure out why my array wasn’t retrieved properly. If this isn’t written anywhere, then other developers would get confused as well.

[LightningLion58]

Hello, thank you
I would expect that if there’s a gap it would be replaced with nil. That does happen when there are 4 indexes for example, just not with 3, which is inconsistent (and doesn’t make much sense).

@VegetationBush

If there are holes in the array, it might be treated as a dictionary. The engine also converts all non array indices to strings.

Thank you, that seems to explain the keys turning to strings.
I guess I’d have to go around that with using tostring to get the values.

[noblemaxx (monkeybaby)]

Yeah not sure about the inconsistencies I had this issue with my inventory system but I found that replacing empty slots with a nil placeholder, like “” or “_” was easier than converting to strings every time

[Wigglyaa]

@LightningLion58

This is an issue because I could not find this behavior documented anywhere in the datastores page.

I couldn’t either, there is this warning in the remote events section:

Table indexing
If you pass a table of data, do not pass a mixed table of numeric and string keys. Instead, pass a table that consists entirely of key-value pairs (dictionary) or entirely of numeric indices.

Whether passing a dictionary table or a numerically indexed table, avoid nil values for any index.

This isn’t the first time someone has had an issue with this ‘feature’

Can someone please explain this to me? My data on the client is not matching up

[Screenshot 2025-03-05 171513] [Screenshot 2025-03-05 171910] [Screenshot 2025-03-05 171920]

[VegetationBush (FartedWayTooHard)]

Yes, and that’s unfortunately why arrays shouldn’t have nil values (because the behavior is undefined). I’ve run into the same issue before, so maybe these responses may help you understand a little better:

@buildthomas

# only behaves the way you expect on arrays, which are sequences of non-nil values starting at index 1 up to an index N, leaving no holes.

Since you have a hole at index 3, your sequence stops at index 2, so only up to that value is considered.

This is covered in the Lua 5.1 spec that Luau is based off: Lua 5.1 Reference Manual

Luau does not spec out # specifically (see Syntax - Luau) so it inherits the Lua 5.1 spec for that operator as in the link above.

This is not a bug, it conforms to the spec.

@Eestlane771

To add to @buildthomas’s answer above, the # operator will do a binary search for the end of the array.
An array is defined as a table with numeric keys 1-n and no further keys after n. However, your array contains holes, meaning you get undefined behavior that should not happen per spec, and thus can be optimized with the assumption that you will never allow an array with holes in it to be #'d.

Compare these two lines:

print(#{[1] = 1, [2] = 2, [4] = 4, [5] = 5}) -- prints 5
print(#{[1] = 1, [2] = 2, [3] = 3, [5] = 5}) -- prints 3

In the first case, it checks for 1, then 2, then 4, then 8, then 6, then 5.
In the second case, it checks for 1, then 2, then 4, then 3.

ipairs works as expected because it doesn’t need to find the end of the array in advance, it needs to iterate through the array one step at a time anyway.

[tnavarts]

As with many other engine systems, the only tables that DataStores support are arrays (integer keys without any nil gaps) and maps with string keys.

Anything else such as including gaps or mixing string and integer keys is undefined behavior.

[PeZsmistic]

FWIW Roblox documentation accepts community contributions. There’s a button on the applicable pages. Your contribution needs to be high quality to be accepted though, not just lazily thrown in.