[Search Pipelines] How should we handle default pipelines for multiple indices? Aliases? Wildcards?

[msfroh]

Is your feature request related to a problem? Please describe.
In #7470, we added the ability to specify a search pipeline that will execute by default for queries against a single index (unless another search pipeline is mentioned in the search request). This only kicks in when the search request is targeting a single index, though. A request that spans multiple indices won't apply a default search pipeline even if any (or all) of the indices has a default specified.

Even if an index has a default search pipeline specified, a request made against an alias for that index would also not use the search pipeline.

Describe the solution you'd like
I'm not sure what the correct behavior should be.

I can see a few options:

1. Try resolving default search pipelines for all underlying indices (after resolving aliases) and transform the request/response only if they all use the same pipeline.
2. Clone the search request and allow each index's default pipeline to transform the request/response -- I don't like this, because it goes against the model where the response processors run after results have been collated across all shards.
3. Do what we currently do, i.e nothing, unless the user specifies a search pipeline at the request level.

There are probably other options that make sense that I haven't thought of.

Describe alternatives you've considered
I haven't really considered alternatives (besides the ones listed above).

This issue is here to figure out (and implement or not implement) the right option based on feedback from people who will use search pipelines.

Additional context
N/A

[peternied]

@msfroh There is a feature request for Views [1], maybe controlling how pipelines are executed could be built into this specification, what do you think?

• [1] Data projection with views #6181

[msfroh]

Woops! I accidentally duplicated this issue over at #11058, which I've now closed to bring things back over here.

As I commented there, I agree with @peternied's suggestion that a new "view" concept is probably the best way forward. Sorry I missed your comment on this issue!