Troubleshooting: UI Warning: The actual value is different what what is displayed

Condition or Error

UI displays the message The actual value is different what what is displayed

Causes

When JSON is ingested into LogScale, there is no limit to how big number values can be, since there is no limit specified for number size in the JSON specification. However, if the JSON is later parsed in a browser environment, it will be parsed as a Javascript number which is a 64-bit float.
64-bit floats have a maximum and minimum safe value for integers:
js
```
Number.MAX_SAFE_INTEGER
9007199254740991
```
to
js
```
Number.MIN_SAFE_INTEGER
-9007199254740991
```
If the number is outside of these bounds, the integer value will lose precision:
js
```
9223372036854775807
```
Will become:
js
```
9223372036854776000
```
If nothing was done to address this, the user would see the imprecise value in the user interface, and field interactions would not work as expected. For example a filter interaction would filter on the wrong value.

Solutions

LogScale detects numbers out of the safe integer bounds for 64-bit floats, and attempts to locate the original value in the event. If LogScale finds a matching field name, it will replace the inexact JSON value with the value of the LogScale field, which has full precision. In most cases this means the precision and functionality will be fully restored.
If an identical LogScale field name is present
If the path to the field in JSON matches the LogScale field name exactly, for example if both the path in the JSON data and the LogScale field is q.ingestTime, we consider it an exact match and do not display any warning.
For instance this will be the case if the @rawstring contains JSON, and parseJson() is used to parse it into LogScale fields without a prefix.
logscale
```
@rawstring := "{\"q\": {
  \"ingestTime\": 9223372036854775807 }}"
| parseJson()
```
In this example q.ingestTime is a field in both the JSON structure, and in the LogScale event.
If a prefixed LogScale field is present
If the path in the JSON data is q.ingestTime and the LogScale field name is prefixed with e.g. s. as s.q.ingestTime, LogScale will consider this an inexact match. LogScale uses the value from s.q.ingestTime to replace the JSON value to restore precision, and underlines the value to warn the user. In this case, the user should verify that the correct LogScale field is used as a replacement.
This is the case in the following LogScale query:
logscale
```
@rawstring := "{\"q\": {
  \"ingestTime\": 9223372036854775807 }}"
| parseJson(prefix = "s.")
```
The following warning will be displayed along with information about which field was used to replace the value:
If no matching LogScale field can be found
When LogScale can't locate either an exact match or a prefixed match, the imprecise JSON value will be displayed along with a warning to the user. In this case, the value might differ from the value in the serialized JSON, and field interactions might not work as expected.

Consider stringifying big integers on ingest
If you control the data format yourself, and your data contains numbers which cannot be precisely represented as 64-bit floating point numbers, consider sending them as a string in the raw JSON data instead. This will guarantee that no precision is lost when the JSON is deserialized. Field interactions on stringified numbers will still work as before in LogScale.