Note: Although the API documentation specifies number as the parameter for Content.fromAssetId, it also accepts numeric string inputs (strings containing digits) in practice.
The critical issue is that Content.fromAssetId attempts to parse these numeric string inputs as numbers internally. This causes unintended precision loss and integer overflow because it forces the safe string data through Lua’s floating-point number limits.
In contrast, Content.fromUri correctly treats strings as literals without parsing.
-- Case 1: Precision Loss (Rounding)
-- Even though we pass a numeric string, it gets rounded like a number.
local largeId = "83294909978786686" -- 17 digits
print("Original String:", largeId)
print("fromAssetId:", Content.fromAssetId(largeId).Uri) -- INCORRECT (Rounds to ...88)
print("fromUri:", Content.fromUri("rbxassetid://" .. largeId).Uri) -- CORRECT
print("------------------------------------------------")
-- Case 2: Integer Overflow
-- Passing MaxInt64 as a string still causes overflow.
local maxInt = "9223372036854775807"
print("Original MaxInt:", maxInt)
print("fromAssetId:", Content.fromAssetId(maxInt).Uri) -- INCORRECT (Overflows to negative)
print("fromUri:", Content.fromUri("rbxassetid://" .. maxInt).Uri) -- CORRECT
Expected behavior
While I understand that precision loss is expected when passing a raw number (due to Luau’s 64-bit floating point limitations), this should not happen when passing a numeric string.
If the input is provided as a string, Content.fromAssetId should treat it as a literal text and simply prepend rbxassetid:// without attempting any internal numeric casting.
Input (Number): fromAssetId(9223372036854775807) → Overflow expected (User error / Engine limit).
Input (Numeric String): fromAssetId(“9223372036854775807”) → Should result in rbxassetid://9223372036854775807 (Exact match).
The function should respect the input type and preserve the string data exactly as provided.