[BUG] JSON parsing issue in Discover since upgrade to v2.12

[lsoumille]

Describe the bug

We upgraded our OpenSearch cluster from version v2.11.1 to v2.12.0. Since then, for one of our index pattern we are not able to retrieve the entries in Discover. We are getting a red toast notification containing "Expected ',' or '}' after property value in JSON at position 3045 (line 1 column 3046)"

When looking at the network request in the browser console, we can see that OpenSearch returned the expected response. (I can share the JSON through more restricted channels if needed):

I tried also to replay the query in OpenSearch console with a similar behaviour. I have an exception even if the expected data from Opensearch is here:

I looked in Opensearch and Opensearch dashboards logs but I did not find any useful message to help troubleshooting this issue.

We are able to make queries log explorer using PPL without issue.

Expected behavior
A clear and concise description of what you expected to happen.

OpenSearch Version
2.12.0

Dashboards Version
2.12.0

Plugins

Please list all plugins currently enabled.

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: WS2022
• Edge and Chrome

Additional context

Add any other context about the problem here.

[lsoumille]

We were able to track down the issue to parseStringWithLongNumerals (https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/packages/osd-std/src/json.ts#L111) in particular in this line https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/packages/osd-std/src/json.ts#L119

The regex is matching a Long Numeral in our raw message. It adds the marker but doesn't remove it afterward resulting in a wrongly formatted JSON. Find it below:
"message":"Feb 23 09:21:59 192.168.200.74 Feb 23 09:21:59 pa-5220-2 1,2024/02/23 09:21:59,013201021186,THREAT,url,2562,2024/02/23 09:21:59,10.10.10.10,10.10.10.10,10.10.10.10,10.10.10.10,NET-SEC-20180423T1847,contoso\\\\john,,web-browsing,vsys1,Internal,ISP,ae1.3001,ae1.997,Profile-LogForwarding,2024/02/23 09:21:59,3687451,1,53853,443,37488,443,0x1403000,tcp,alert,\\"outlook.office365.com/autodiscover/autodiscover.json\\",9999(9999),computer-and-internet-info,informational,client-to-server,"෴7232670279194071601",0x0,10.0.0.0-10.255.255.255,Germany,,application/json,0,,,1,Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.17029; Pro),,,,,,,0,0,0,0,0,Edge-FW,pa-5220-2,,,,get,0,,0,,N/A,N/A,AppThreat-0-0,0x0,0,4294967295,,\\" Restricted-Internet-Access-URLs,computer-and-internet-info,low-risk\\",57befe9c-bada-402a-96b9-3cff7d5be86f,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0,2024-02-23T09:21:59.010+01:00,,,,internet-utility,general-internet,browser-based,4,\\"used-by-malware,able-to-transfer-file,has-known-vulnerability,tunnel-other-application,pervasive-use\\",,web-browsing,no,no,"

I think it could interest you @AMoo-Miki

[AMoo-Miki]

This sounds like a mixed use of longnumerals in Discover. I will find out more and report back.

This is a problem with long numerals handling in @osd/std. The quotes are confusing it. I will need to figure out how to un-confuse it.

[3ster]

This issue still occurs for me on Brave, even after applying the fix in #5956, presumably due to the added regex not matching the error message's exact wording. The contents of e.message in Brave are similar to the error message mentioned by the original issue creator: Expected ',' or ']' after array element in JSON at position 1551490 (line 1 column 1551491)

Changing the regex in

OpenSearch-Dashboards/packages/osd-std/src/json.ts

Line 180 in 45096bb

match = e.message.match(/expected .*at line (\d+) column (\d+)(\s|$)/);

from expected .*at line (\d+) column (\d+)(\s|$) to [Ee]xpected .*line (\d+) column (\d+)(\s|$|\)) causes the parsing to work as expected.
This regex also seems to still match the error message in #6017, with the example document there exhibiting the correct behavior after applying the above-mentioned change.

[kingnarmer]

Is there a way to workaround this error I can do to get my logs to show . Thanks

[AMoo-Miki]

@3ster thanks for your help here. I have made a more generalized set of regexs for this but am having trouble finding a way to test them. Do you have a piece of data that fails normally for you that I can use to test?

[3ster]

Yes, the snippet in #6017 consistently triggers this behavior:

POST myindex/_doc
{
  "@timestamp" : "2024-03-04T09:40:08.2531122Z",
  "JustAKeyword" : "10080214256450617947,2031884987996059597,1"
}

I've also noticed that this issue manifests in Safari in a different way, resulting in SyntaxError: JSON Parse error: Unrecognized token '෴'. Since Safari's JS engine doesn't seem to expose the line/column in which the error occured, I'm afraid a completely different approach is needed to get the parsing to work as it does in other browsers. Note that triggering this error via the OpenSearch Dev Tools Console completely bricks said console until the history is manually wiped from local storage.