The way queries and aggregations deal with with unmapped fields is inconsistent. For example the nested query fails if the defined path doesn't point to an object field, but the nested aggregator doesn't fail and just returns an empty bucket. How the search api should deal with unmapped fields is application specific, so how ES should deal with unmapped fields should become controllable from the search api.

The idea is to add unmapped_fields top level field to the search api (and maybe also be settable via a query string parameter). All features that interact with the mapping (queries, aggregations) should take this setting into account and act accordingly.

The unmapped_fields field should support the following setting:

• error, returns a parse error if a field can't be resolved by the mapping. I think this should be the default.
• ignore, ignores the query or aggregation in question and returns no results.
• warn, like ignore, but also prints a warning in the log if a field can't be resolved.

I think initially we should support the unmapped_fields option for the following queries/aggregations:

• nested query.
• has_child query.
• has_parent query.
• nested aggregation.
• reverse_nested aggregation.
• children aggregation.
• Maybe also the features around geo point and geo shape?

See PR #9521 for the initial discussion.