Maybe you should change the parameter name here to allow_multiple_values:true|false, as discussed in #80825, #58523 and https://github.com/elastic/ecs/blob/main/rfcs/text/0029-enforce-single-value-fields.md

I just saw there is an open PR for adding allow_multiple_values parameter (#80289)

@markharwood do you think we should wait for your PR to be merged?

yeah, this parameter is useful, I can wait for #80289 merged, then change the aggregate_metric_double logic

My PR changes the main DocumentParser parsing logic to reject documents with arrays where allowMultipleValues is false for a field. Currently only user-defined mappings set this flag.
The PR does not tackle changes to existing single-valued fields like AggregateDoubleMetricFieldMapper that have implemented their own singularity checks (which I understand here have performance issues).

This is perhaps an argument for committing #80289 and creating a follow-up one for fields like AggregateDoubleMetricFieldMapper to strip out their singularity checks and override the new FieldMapper. allowMultipleValues() to return false. This would mean for always-singular fields like this, the central DocumentParser class would quickly reject any arrays at source. One complication that may need addressing is that the existing Lucene document-level singularity-checking code probably handles scenarios where the double field is singular but is contained in an object that might be repeated in an array e.g.[ { "num": 1}, {"num":2} ] rather than "num":[1,2]. The DocumentParser may need extra logic to spot the former.
Thoughts @jpountz ?

yeah, It's maybe not equals to single value. your PR reject the array value, but if a field in a object array, like your example: [ { "num": 1}, {"num":2} ], it may be duplicate in lucene. the AggregateDoubleMetricFieldMapper need a single value in lucene, not only array case. e.g:

{
	"field": [{
		"min": 10.0,
		"max": 50.0,
		"value_count": 3
	}, {
		"min": 11.0,
		"max": 51.0,
		"value_count": 3
	}]
}

it's not allow like this.

Right, so the DocumentParser would keep tracks of when it enters and exits arrays while parsing. Any field flagged as allow_multiple_values:false would cause an error if the current parse context was inside an array (no matter the nesting depth).

yeah, when your PR merged, I will change the AggregateDoubleMetricFieldMapper code to adapt the parameter.

Perhaps you can change the mapping parameter from single_value to allow_multiple_values with the following semantics:

Should the field permit arrays of values? Accepts true
(default) or false. When false, documents presenting arrays
of values for this field will be rejected with an error.

So that we are consistent with what the Mark's design

okay, I will change it.

Thank you!

Is there any reason why this test is in WholeNumberFieldMapperTests and not in NumberFieldMapperTests?

I guess that you extractIllegalArgumentException from this MapperParsingException because you want to bubble up the underlying error instead of throwing a generic message like this `"failed to parse field [field.value_count] of type [integer] in document with id '1'.".

If that's the case, can you please add a comment here to document the thinking behind this?

Here we receive a very generic error message. I think it's worth throwing the more informative: Field [field] of type [aggregate_metric_double] does not support indexing multiple values for the same field in the same documet.

Do you think that's possible?

👍