Skip to content

Move resolve aliases to IndexAbstractionOptions#143953

Open
jfreden wants to merge 4 commits intoelastic:mainfrom
jfreden:move_resolve_aliases
Open

Move resolve aliases to IndexAbstractionOptions#143953
jfreden wants to merge 4 commits intoelastic:mainfrom
jfreden:move_resolve_aliases

Conversation

@jfreden
Copy link
Contributor

@jfreden jfreden commented Mar 10, 2026

This is a follow up from #143741 to also move resolve aliases to IndexAbstractionOptions.

elasticsearchmachine pushed a commit that referenced this pull request Mar 11, 2026
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).
@jfreden jfreden force-pushed the move_resolve_aliases branch from 6010006 to 015e98e Compare March 12, 2026 09:42
@jfreden jfreden force-pushed the move_resolve_aliases branch from 30caf92 to 1402f33 Compare March 12, 2026 10:07
@elasticsearchmachine elasticsearchmachine added the serverless-linked Added by automation, don't add manually label Mar 12, 2026
@jfreden jfreden marked this pull request as ready for review March 12, 2026 12:18
@jfreden jfreden added the :Security/Security Security issues without another label label Mar 12, 2026
@jfreden jfreden requested review from idegtiarenko and n1v0lg March 12, 2026 12:19
@elasticsearchmachine elasticsearchmachine added the Team:Security Meta label for security team label Mar 12, 2026
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)


public static Builder builder(IndexAbstractionOptions indexAbstractionOptions) {
return new Builder(indexAbstractionOptions);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: we have 2 static builder methods today: one for starting from scratch and one to start editing other abstraction. I wonder if we should change it to be instance method:
IndicesOptions.builder(options.indexAbstractionOptions())...build() -> options.indexAbstractionOptions().builder()...build().

It is different from existing approach but it looks a bit cleaner to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that is a lot nicer, but the other IndicesOptions are using that style of builder so I think it would be inconsistent and require a full refactor of all of them, which I think is out of scope for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this is not blocking this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>non-issue :Security/Security Security issues without another label serverless-linked Added by automation, don't add manually Team:Security Meta label for security team v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants