Two edge cases we ran into with the bundled JsonFx parser

[LEE JONG GUN]

Hello!
While storing richer JSON documents through CustomEntityService we ran into two
edge cases in the bundled JsonFx parser (Runtime/JsonFx/JsonReader.cs) that we thought
might be worth sharing, in case other Unity developers hit them too.

1. InvalidCastException when an array-of-arrays mixes inner array shapes (Unity/Mono)

Passing this document as the dataJson of CustomEntityService.CreateEntity throws
before the request is even sent:

{ "p": [ [ {"x": 1} ], [] ] }

Also reproduces when the second inner array is all nulls instead of empty.
ReadArray infers a dictionary-array type from the first inner array, then upgrades
arrayItemType to object-array on the mismatched one, and the final
ArrayList.ToArray call throws under Mono's Array.Copy.
A small fallback resolved it for us — wrapping that ToArray call in try/catch and
falling back to the plain object-array ToArray.

2. Integers with 19+ digits (18+ when negative) silently lose precision

ReadNumber routes integers with precision of 19 or more to Double.Parse, so a value
like long.MaxValue (9223372036854775807) becomes 9.223372036854776E18 with no error.
Note that precision includes the minus sign, so negative 18-digit integers take the
double path as well. This range is easier to hit than it may look — snowflake-style
IDs (Discord, Twitter/X) are 18-19 digit integers, and long-running idle-game
currencies get there too.

What worked for us was raising the threshold to "precision < 29":

• The integer path already parses through Decimal.Parse, so only the boundary changes.
• 28 digits is the largest length Decimal.Parse can always hold exactly
  (decimal.MaxValue is about 7.9e28, a 29-digit number, so some 29-digit values
  would overflow — hence 29 is the widest safe boundary).
• Since precision counts the sign, negative values are effectively capped at 27
  digits — still comfortably covering the full long range.
• Values that fit in long still come back as long; 20-28 digit values fall through
  to decimal, which JsonWriter already emits as a quoted string when it exceeds
  IEEE754 range — so precision is preserved end to end.
• 29+ digit integers keep the existing double behavior.

We're currently carrying both changes as local patches.

Thank you!

[Michael Costa]

Thanks for letting us know and your own solutions! We'll see if we can patch this into the JsonFx library we're using for future versions of brainCloud to avoid these edge cases.