Handle views in ResolveIndexAction by idegtiarenko · Pull Request #143561 · elastic/elasticsearch

idegtiarenko · 2026-03-04T08:57:27Z

This change ensures that GET /_resolve/index/{pattern} is not failing if it matches one or several views

elasticsearchmachine · 2026-03-04T08:57:53Z

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

jfreden

Thanks for working on a fix for this!

I think this should be handled earlier and more generally so other methods could pick this up too, ideally in the IndexNameExpressionResolver::ensureAliasOrIndexExists. Views should be hidden unless explicit index options to fetch them are used. Unfortunately there is only the IndicesOptions.wildcardOptions.resolveViews to check that now, there isn't one specifically for concrete view references.

idegtiarenko · 2026-03-04T10:24:18Z

Possibly we want to return views from IndexNameExpressionResolver to add/integrate them into FieldCaps.
let me take a look on alternatives. Maybe we in fact need another flag in options (Possibly in ConcreteTargetOptions?)

idegtiarenko · 2026-03-04T15:13:30Z

server/src/main/java/org/elasticsearch/action/admin/indices/resolve/ResolveIndexAction.java

-            List<ResolvedDataStream> dataStreams
-        ) {
-            resolveIndices(names, indicesOptions, projectState, resolver, indices, aliases, dataStreams, Collections.emptySet());
-        }


Inlined method used only in test. We should not have test only code in production

idegtiarenko · 2026-03-04T15:16:30Z

server/src/main/java/org/elasticsearch/cluster/metadata/IndexNameExpressionResolver.java

                throw infe;
            }
        }
+        if (indexAbstraction.getType() == Type.VIEW && context.getOptions().wildcardOptions().resolveViews() == false) {


This skips view when targeted directly by name.
Ideally we should not rely on a wildcard option for this.
For now I would like to merge fix as is to fix affected api.

Eventually (but before it is released) we should replace options.wildcardOptions.resolveViews with something related to concrete views, not just patterns.
cc @n1v0lg

Something to note is that resolveAliases also only exists in the WildcardOptions, so if we add some new IndicesOptions subcategory it should probably be migrated there too. Unclear if it's worth the effort, but that's for a different investigation.

Opened this PR to move them: #143741

jfreden

LGTM!

jfreden · 2026-03-04T15:42:24Z

server/src/main/java/org/elasticsearch/action/admin/indices/resolve/ResolveIndexAction.java

            if (names.length == 1 && (Metadata.ALL.equals(names[0]) || Regex.isMatchAllPattern(names[0]))) {
                names = new String[] { "**" };
            }
+            assert indicesOptions.wildcardOptions().resolveViews() == false : "Views are not supported in ResolveIndexAction";


piergm

LGTM!

idegtiarenko · 2026-03-04T16:17:30Z

x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test/esql/200_view.yml

        index: myview
        body: { query: { match_all: {} } }

-  - length: { hits.hits: 0 }


This change also causes a _search query to fail rather than pass with 0 results.
I think this is less surprising, but maybe @craigtaverner could confirm if this is desired.

I think the change in behaviour makes sense.

craigtaverner

LGTM. I think we might want to add a test that gets the old error message (write to a view), but that could easily be another PR. It is missing scope from the original work, not really relevant to this PR.

craigtaverner · 2026-03-05T15:01:15Z

...l/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/ResolveIndexActionIT.java

+            emptyIterable()
+        );
+
+        // matched view is not returned, but it does not fail request


Should this comment move a few lines down and a new comment be here, since we are indeed failing the request when an explicit view name is used.

craigtaverner · 2026-03-05T15:05:08Z

x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test/esql/200_view.yml

        index: myview
        body: { query: { match_all: {} } }

-  - length: { hits.hits: 0 }


I think the change in behaviour makes sense.

craigtaverner · 2026-03-05T15:05:17Z

x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test/esql/200_view.yml

-
  - do:
-      catch: /an ESQL view \[myview\] may not be the target of an index operation/
+      catch: /no such index \[myview\]/


I think the change in behaviour makes sense. But I also note that we should get the old error message if we write to write to a view, and there is no test for that. We could add such a test in a separate PR, or here.

coderabbitai · 2026-03-10T09:13:22Z

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (2)

Team:Delivery
Team:Search - Inference

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: be455d03-cf00-4711-bc85-08b0ab3502f3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

…locations * upstream/main: (126 commits) Update KnnIndexTester to use more settings from datasets (elastic#143869) fix: dynamic template vector array is overridden by automatic dense_vector mapping (elastic#143733) ES|QL: Don't reuse the same alias for _fork column (elastic#143909) Close and initialize clients after each node upgrade in logsdb rolling upgrade tests. (elastic#143823) ESQL: Added GroupedTopNOperator for LIMIT BY, compute only (elastic#143476) Handle views in ResolveIndexAction (elastic#143561) Improve reindex rethrottle API in stateless (elastic#143771) Use a copy of the SearchExecutionContext for each Percolator execution (elastic#142765) Log the stacktrace when we encounter a deprecation warning for `default_metric` (elastic#143929) ESQL: evaluate ReferenceAttributes to potentially FieldAttributes for full-text functions restriction (elastic#143893) Add ClusterStateSerializationStats Serializatation Tests (elastic#142703) Adds Coordination Diagnostics Tests (elastic#142709) Upgrade Elasticsearch to Apache Lucene 10.4 (elastic#141882) ESQL: Add configurable bracket-based multi-value support for CSV reader (elastic#143890) time series es819 binary dv use up to a 1mb block size (elastic#143049) Dynamically enable / disable plugins in correspondence to stateless mode. (elastic#142147) ES|QL: Implement first/last_over_time for tdigest (elastic#143832) Document CHANGE_POINT limitation (elastic#143877) Fix OperationsOnSeqNoDisabledIndicesIT (elastic#143892) [Test] Test that sequence numbers are not pruned with retention lease (elastic#143825) ...

@idegtiarenko

There has been several discussions on this topic since I opened #141050 and @idegtiarenko also mentioned this in #143561 (comment). The issue is that both `resolveViews` and `resolveAliases` are in `WildcardOptions` but are used when resolving both concrete index pattern targets and wildcard targets. This PR moves `resolveViews` from `IndicesOptions.WildcardOptions` into a new `IndicesOptions.IndexAbstractionOptions` record to address this confusing inconsistency. This is in preparation for sending `resolveViews` as a parameter to field caps for remote view resolving where more work will be done to serialize `resolveViews` and not having this in place would make for confusing code. See #143384 for more information on the upcoming serialization of `resolveViews`. **_Note_**: `resolveAliases` is moved in a follow up PR since it's decoupled from the resolveViews changes. #143953 **_Note_**: `IndicesRequest.includeDataStreams()` is the same type of flag as `resolveAliases` and `resolveViews`, it controls whether data streams participate in index resolution. It's a candidate for `IndexAbstractionOptions` but currently lives on `IndicesRequest` (not `IndicesOptions`) and is threaded separately through `IndexNameExpressionResolver.Context` as a constructor parameter. Moving it would touch 60+ files and change the `IndicesRequest` interface. Because of how big that change would be, I have not considered doing that in this PR (or at all).

Handle views in ResolveIndexAction

f1f2d52

idegtiarenko requested review from craigtaverner and jfreden March 4, 2026 08:57

idegtiarenko added >non-issue Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) :Analytics/ES|QL AKA ESQL v9.4.0 labels Mar 4, 2026

idegtiarenko added 3 commits March 4, 2026 10:24

fix style

bc14932

fix style

d2f5158

Merge branch 'main' into fix_resolve_index

a04d737

jfreden requested changes Mar 4, 2026

View reviewed changes

idegtiarenko added 3 commits March 4, 2026 15:44

inline test only method

165abbf

skip concrete views

97c6455

Merge branch 'main' into fix_resolve_index

90b9135

idegtiarenko requested review from jfreden, n1v0lg and piergm March 4, 2026 15:12

idegtiarenko commented Mar 4, 2026

View reviewed changes

jfreden approved these changes Mar 4, 2026

View reviewed changes

piergm approved these changes Mar 4, 2026

View reviewed changes

fix specs

211c085

idegtiarenko commented Mar 4, 2026

View reviewed changes

Merge branch 'main' into fix_resolve_index

e92056c

craigtaverner approved these changes Mar 5, 2026

View reviewed changes

jfreden mentioned this pull request Mar 9, 2026

Move resolve views to IndexAbstractionOptions #143741

Merged

idegtiarenko added 2 commits March 10, 2026 10:12

remove unused check

a2dc36a

Merge branch 'main' into fix_resolve_index

2c08b88

idegtiarenko merged commit c2e36ed into elastic:main Mar 10, 2026
36 checks passed

idegtiarenko deleted the fix_resolve_index branch March 10, 2026 13:01

Conversation

idegtiarenko commented Mar 4, 2026

Uh oh!

elasticsearchmachine commented Mar 4, 2026

Uh oh!

jfreden left a comment

Choose a reason for hiding this comment

Uh oh!

idegtiarenko commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jfreden left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

piergm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

craigtaverner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot commented Mar 10, 2026

Review skipped

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

idegtiarenko commented Mar 4, 2026 •

edited

Loading

jfreden left a comment •

edited

Loading