Remotes Throw Errors When Passed Boolean-Keyed Tables

Bug Reports Engine Bugs
,
#1

I’ll preface this by saying I’m uncertain as to whether this would be classified as a documentation bug because the behavior is intended but not documented or if it is indeed an engine but because the behavior is unintended.

When attempting to pass a table with boolean keys through any Remote... or UnreliableRemote... object, the call will raise an error with the following error message: “Invalid table key type used”

This can be demonstrated by pasting the following code into a server-side script on an empty baseplate and stepping on the button it generates:

--!strict

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

-- This will be sent to the client.
local Payload = {
	[true] = "Hello";
}

-- -- --

local Active = false

local Color_ByActive = {
	[true] = BrickColor.new("Bright red");
	[false] = BrickColor.new("Bright green")
}

-- -- --

local Remote = Instance.new("RemoteEvent", ReplicatedStorage)

local Button = Instance.new("Part")
Button.Anchored = true
Button.BrickColor = Color_ByActive[Active]
Button.CFrame = CFrame.Angles(0, 0, 0.5 * math.pi) + Vector3.new(0, 0.2, -16)
Button.Shape = Enum.PartType.Cylinder
Button.Size = Vector3.new(0.4, 4, 4)
Button.Parent = workspace

Button.Touched:Connect(function(Hit)
	
	if Active then
		return
	end
	
	local Character = Hit:FindFirstAncestorWhichIsA("Model")
	local Player = Character and Players:GetPlayerFromCharacter(Character)
	
	if Player then
		
		Active = true
		Button.BrickColor = Color_ByActive[Active]
		
		local Success, Reason: any = pcall(
			Remote.FireClient,
			Remote,
			Player,
			Payload)
		
		if Success then
			print(string.format("Successfully messaged player %s!",
				Player.Name))
		else
			warn(string.format("Failed to message player %s for reason: %*",
				Player.Name,
				Reason))
		end
		
		task.wait(2)
		
		Active = false
		Button.BrickColor = Color_ByActive[Active]
	end
end)

While it likely goes without saying, the workaround for this problem is to simply not use boolean keys in networked tables.

Expected behavior

Ideally, boolean keys would be valid table keys when performing remote calls, as there is no indication in the documentation that they wouldn’t be, although this might be more of a feature request. Even if they are not supported outright, Remote Limitations documentation suggests that they would at least be stringified. Outside of cyclical tables or legitimate argument mismatches, I do not expect my remote calls to throw errors prior to actually making the call.

#2

Thank you for highlighting this! This is more a feature request and we’ve added to our backlog for review.

1 Like