[BUG] Large values do not display correctly in OpenSearch Dashboards

[dlvenable]

Describe the bug

Large long values display incorrect values in OpenSearch Dashboards. These large values appear to lose precision or in some cases show slightly different values in the less significant digits.

To Reproduce
Steps to reproduce the behavior:

1. Download this Docker compose file.
2. docker compose up
3. Run the following _bulk request:

curl -k -u "admin:admin" https://localhost:9200/_bulk -X PUT --header 'Content-Type:application/json' -d '{"index":{"_id":"TEST1","_index":"test-input"}}
{"VeryLargeValue":1234567891011121314,"Version":1,"Name":"TEST1"}
{"index":{"_id":"TEST2","_index":"test-input"}}
{"Version":2,"VeryLargeNumber":1234567891011121314,"Name":"TEST2"}
'

4. Use curl to verify it is correct:

curl -k -u "admin:admin" 'https://localhost:9200/test-input/_search?pretty'

5. Load http://localhost:5601/app/dev_tools#/console
6. Paste and execute:

GET test-input/_search
{
  "query": {
    "match_all": {}
  }
}

7. See that the values are not quite correct:

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "test-input",
        "_id": "TEST1",
        "_score": 1,
        "_source": {
          "VeryLargeValue": 1234567891011121400,
          "Version": 1,
          "Name": "TEST1"
        }
      },
      {
        "_index": "test-input",
        "_id": "TEST2",
        "_score": 1,
        "_source": {
          "Version": 2,
          "VeryLargeNumber": 1234567891011121400,
          "Name": "TEST2"
        }
      }
    ]
  }
}

8. Create an index pattern and view in Discover tab.

Expected behavior

Using OpenSearch Dashboards, I should see all these values correctly.

OpenSearch Version

OpenSearch 2.9
OpenSearch 2.11

Dashboards Version

Dashboards 2.9
Dashboards 2.11

Plugins

Standard

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: macOS
• Firefox

[dlvenable]

Results from curl showing the data is correct in OpenSearch:

curl -k -u "admin:admin" 'https://localhost:9200/test-input/_search?pretty'

{
  "took" : 29,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "test-input",
        "_id" : "TEST1",
        "_score" : 1.0,
        "_source" : {
          "VeryLargeValue" : 1234567891011121314,
          "Version" : 1,
          "Name" : "TEST1"
        }
      },
      {
        "_index" : "test-input",
        "_id" : "TEST2",
        "_score" : 1.0,
        "_source" : {
          "Version" : 2,
          "VeryLargeNumber" : 1234567891011121314,
          "Name" : "TEST2"
        }
      }
    ]
  }
}

[AMoo-Miki]

David, #5095 addressed this in 2.11. I will check to see if anything changed between in being merged and the release.

[AMoo-Miki]

Here is what I found:

• Long numerals were only supported in the Dev Tools prior to being broken in 2.9 and fixed in 2.11.
• Long numerals never worked in Discover, Search, Filters, or any of the visualizations. I have [Discover] Add long numerals support #5592 to add this feature to Discover, Search, and Filters; visualizations will have to wait for someone else to add this.

I am looking to see why you are getting results that don't match expectations.

[AMoo-Miki]

On a 2.11.1, I have confirmed that long numerals work in the Dev Tools, as expected. Will try to reach out offline and figure out the circumstances.

[dlvenable]

@AMoo-Miki , Thank you for working on this issue.

I have tested this on both OpenSearch 2.11.0 and 2.11.1. I do not see this bug on either of those versions. So I'll go ahead and close the issue.

[seaneez]

Hello, @AMoo-Miki

Thank you for fixing the long type number display issue.

We are currently using values that correspond to the unsigned long type, but precision errors still occur with such large numbers.

Could you please fix the bug so that unsigned long type numbers are also displayed accurately?