[ilyannn]

Note: drafted with 🤖 Claude Code/Claude Opus 5.5 under my supervision.

Why

elastic/elastic-package#4140 makes the fields validator in pipeline and system tests stricter for packages with format_version 3.8.0 or later. Package authors should learn about it when they bump the format version, so it belongs in the spec changelog.

Until now, fields mapped as integer, short, byte, unsigned_long, half_float or scaled_float accepted any value, including strings like "-89 dBm". Only long, float and double were type-checked. elastic/integrations#22237 (fortinet_fortigate) is an example: unit-suffixed strings in type: integer fields passed elastic-package test pipeline.

What

One breaking-change entry under 3.8.0-next in spec/changelog.yml. From 3.8.0, string values in those six types fail validation, as they already do for long, float and double, unless the field is listed in string_number_fields.

For all format versions, elastic-package also rejects values in these fields that Elasticsearch can't coerce to a number at all ("-89 dBm", "Auto", booleans, objects). That part doesn't depend on the spec version, so it isn't in the changelog.

There are no spec file changes. The existing string_number_fields description ("List of numeric type fields allowed to have a string value if it can be parsed as a number") already covers all numeric types.

Rollout

Merge this together with or after elastic/elastic-package#4140. In elastic/integrations main, all packages use format_version 3.4.2 or lower, so this entry doesn't change anything for them until they bump.

Testing

• go test ./code/go/internal passes, which validates the changelog format.