CSV report gets printed with duplicate ids

[bhavyarm]

Kibana version: 8.4.0

Elasticsearch version: 8.4.0

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from downloads

Describe the bug: Kibana's discover is printing the same ids in CSV report.

Ingest:

PUT _template/template_test_elastic
{
  "index_patterns": [
    "prueba_elastic*"
  ],
  "settings": {
    "number_of_shards": 1
  },
  "mappings": {
    "properties": {
      "TIPO_MENSAJE": {
        "type": "keyword"
      },
      "DATE_TIME": {
        "type": "date",
        "format": "yyyyMMddHHmmss||yyyyMMddHHmmssZ||strict_date_optional_time||epoch_millis"
      }
    }
  }
}

 
POST prueba_elastic/_doc/202209071000000604
{
  "DATE_TIME": "20200101130000+0200",
  "TIPO_MENSAJE": "OP"
}

POST prueba_elastic/_doc/202209071000000605
{
  "DATE_TIME": "20200101130000+0200",
  "TIPO_MENSAJE": "OP"
}

POST prueba_elastic/_doc/202209071000000606
{
  "DATE_TIME": "20200101130000+0200",
  "TIPO_MENSAJE": "OP"
}

POST prueba_elastic/_doc/202209071000000607
{
  "DATE_TIME": "20200101130000+0200",
  "TIPO_MENSAJE": "OP"
}

1. Create a data view with test_elastic index pattern
2. Go to discover
3. print csv report

Kibana prints duplicate ids in the csv report

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

our CSV generation is assuming in the given case that the id is a number , and therefore it's converted to a number. However the number is too big and this causes rounding errors (#40183), which lead to duplicate ids. So a possible solution could be for CSV generation to consider the actual mapping of the field to determine if it's a number, or not. A quicker but, intermediate solution could be to always consider _id fields as string.

[Ning2022]

@LeeDr, Hi Lee, this is Ning, APAC support manager. I noticed you are Kibana SDH escalation contact point this week based on https://elastic.pagerduty.com/schedules#PNAOA6T, so I am contacting you here to get your insights. The customer is chasing the ETA for this issue through AE and CSM. Could you help review and share our position and plan on this issue for reducing customer's anxiety? Thanks a lot!

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[LeeDr]

Hi @Ning2022. We were under the impression that a work-around was provided to the customer and so this wasn't a priority. Can you please update us on the success of using the work-around?

[LeeDr]

/cc @italo-cocio Any news on the customer using the work-around for this issue?

[italo-cocio]

Hello @LeeDr

My apologies for this, I thought somehow this piece of info was already in the know of our Dev team.
Customer mentions that the workaround involves a lot of changes in their application and it may cause performance issues, so they are not implementing it.

Thanks

[tsullivan]

Update for the watchers on this issue: it's a priority for the team and we plan to release a fix in the next minor release.

[tsullivan]

accidentally closed when I meant just to comment

[Ning2022]

@tsullivan , Hi Tim, thanks a lot for your update! Great to know we plan to fix it in the next minor release.