@haetamoudi I believe that update_count, connection_count and aggregated_log_count are defined as type: integer within the fields.yml file.
Question 1: do we need to update fields.yml so that these fields are now updated to long?
Question 2: if we update the field definition to long, is it now a breaking change?

cc.ing @taylor-swanson

Pinging @elastic/integration-experience (Team:Integration-Experience)

Question 1: do we need to update fields.yml so that these fields are now updated to long?

Yes, we need to update the fields.yml files in order to store long values. Without the change indexing could fail when the number no longer fits in an the fields defined Elasticsearch data type.

Question 2: if we update the field definition to long, is it now a breaking change?

Not a breaking change IMO. Data types within a field families are safe although the performance characteristics may differ:

• keyword family - keyword, constant_keyword, wildcard
• text family
• numeric - byte, short, integer, long, float, scaled_float, double (not an official field family type)

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 657247e

Failed CI Steps

• Check integrations checkpoint

History

• 💔 Build #32887 failed 575247a
• 💚 Build #32815 succeeded 19080ad

Package checkpoint - 1.41.2 containing this change is available at https://epr.elastic.co/package/checkpoint/1.41.2/