ESQL: fields unrelated to the query can cause serialization failures on older remote data nodes

[alex-spies]

It is acceptable for the fieldNames method, which determines ES|QL's field caps calls, to ask for more fields than are actually used in the query. Example from the tests:

            from employees | sort emp_no | keep emp_no, still_hired | limit 3

The field caps call will also ask for emp_no.* (in case this is a text field and we need its exact .keyword subfield).

After resolution, we create a FieldAttribute for each field found this way and will stuff it into the EsRelation that represents the FROM command.

Later on, this EsRelation becomes part of the data node plan inside a FragmentExec. This fragment is sent to the data nodes.

Problem: The EsRelation may contain fields that are entirely unused in the query. If a remote node cannot deserialize e.g. the field's DataType, the data node will fail - for no good reason. This can happen e.g. when adding a new data type to ESQL: 8.19 nodes will not be able to deserialize FieldAttributes of the new type, so 9.x/8.19 CCS scenarios can fail. This can even affect queries that are already working perfectly, because the mapping on the 9.x cluster evolves and now includes a field of the new type. Of course, rolling upgrades between minor versions are also affected whenever a new data type is added.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[alex-spies]

I think this is related to the more general problem in #135193; solving the latter may also solve this.

[alex-spies]

Closing in favor of #135193. Sending non-deserializable field attributes to older nodes is not acceptable anyway, because even a query like FROM idx | KEEP * should continue working when executed on a new node that somehow has new field attributes that older nodes cannot handle.

That's especially true if the new node supports data types that an older node doesn't. FROM idx | KEEP * will have previously passed the unsupported field through with nulls in the output; so it's unacceptable that the query starts having partial failures on the old node if a newer node, which supports the previously unsupported data type used in idx, acts as coordinator.