Skip to content

Always treat dash-prefixed expression as index exclusion#138467

Merged
elasticsearchmachine merged 22 commits intoelastic:mainfrom
ywangd:index-exclusion-bug-fix
Dec 8, 2025
Merged

Always treat dash-prefixed expression as index exclusion#138467
elasticsearchmachine merged 22 commits intoelastic:mainfrom
ywangd:index-exclusion-bug-fix

Conversation

@ywangd
Copy link
Member

@ywangd ywangd commented Nov 24, 2025

Fixed a bug that dash prefix expressions, including both concrete names and wildcard patterns, are not always treated as index exclusion during index resolution process. The PR also updates relevant document to make the behaviour clear.

Resolves: #64752
Resolves: #83435

@ywangd ywangd added >bug :Security/Security Security issues without another label v9.3.0 labels Nov 24, 2025
@elasticsearchmachine
Copy link
Collaborator

Hi @ywangd, I've created a changelog YAML for you.

@github-actions
Copy link
Contributor

github-actions bot commented Nov 24, 2025

🔍 Preview links for changed docs

@github-actions
Copy link
Contributor

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

@elasticsearchmachine
Copy link
Collaborator

Hi @ywangd, I've updated the changelog YAML for you.

Comment on lines +96 to 106
final var iter = expressions.iterator();
while (iter.hasNext()) {
final ResolvedIndexExpression current = iter.next();
if (expressionsToExclude.contains(current.original())) {
iter.remove();
continue;
}
final Set<String> localExpressions = current.localExpressions().indices();
if (localExpressions.isEmpty()) {
continue;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This change ensures that an expression like foo,bar,-foo work correctly by excluding foo entirely from the ResolvedExpressions. It is so far a CPS only feature and strictly speaking not necessary for stateful code yet. But we would have to mute or skip tests without it. So I decided to include it given the its relative small size.

@ywangd ywangd marked this pull request as ready for review December 1, 2025 01:10
@elasticsearchmachine elasticsearchmachine added the Team:Security Meta label for security team label Dec 1, 2025
@elasticsearchmachine
Copy link
Collaborator

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

@ywangd ywangd requested review from piergm, quux00 and tvernum December 1, 2025 01:10
@ywangd
Copy link
Member Author

ywangd commented Dec 1, 2025

Both indexNameExpressionResolver and IndexAbstractionResolver have the problematic exclusion handling. The former can still take effect when security is disabled. The PR fixes the issues in both places.

Copy link
Contributor

@idegtiarenko idegtiarenko left a comment

Choose a reason for hiding this comment

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

ES|QL will take advantage of this changes once merged as we indirectly use IndexNameExpressionResolver.

Thanks, looking forward for this change to be merged!

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

A user who is snapshotting very-important-index,other-indices*,-*ant* today will, after this change, silently stop having snapshots of very-important-index. I understand that we might like to change this behaviour, even perhaps considering it a bug, but still it's a potentially-data-loss-causing breaking change that at least needs some discussion with the BCC before proceeding.

The original design in which specifically-named indices (no wildcards) are not excluded was a deliberate choice.

@ywangd
Copy link
Member Author

ywangd commented Dec 1, 2025

@DaveCTurner

needs some discussion with the BCC before proceeding

Indeed. There is an approval proposal for this change. I tagged you in Slack for the relevant message. Thanks for checking!

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

Sorry, I was misreading the effects of this change, it doesn't have the impact I initially thought. I'm ok with it now, sorry for the noise.

@DaveCTurner DaveCTurner dismissed their stale review December 1, 2025 08:50

Doesn't have the impact I thought it had.

@@ -0,0 +1,7 @@
pr: 138467
summary: "Fixed a bug that dash prefix expressions, including both concrete names\
Copy link
Contributor

@leemthompo leemthompo Dec 1, 2025

Choose a reason for hiding this comment

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

language nit: I'd rephrase and add examples:

Fixed a bug where dash-prefixed expressions, for both specific index names and wildcard patterns (for example: -system-index, -logs-*), were not consistently excluded during index resolution.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the suggestion. Updated in 1f1d757

@ywangd ywangd requested a review from leemthompo December 2, 2025 04:25
Copy link
Contributor

@leemthompo leemthompo left a comment

Choose a reason for hiding this comment

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

Just couple language issues. I think the note is OK, but I'll let @DaveCTurner weigh in on whether it's clear enough to his eyes

{applies_to}`stack: ga 9.3` A dash-prefixed (`-`) expression is always treated as an exclusion.

::::{note}
In previous versions, such expression is sometimes _not_ treated as an exclusion due to a bug.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use removed 9.3 here?

{applies_to}`stack: removed 9.3`

I think that'd be nicer than a ::::{note} which highlights this whole paragraph as if it's important.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think removed is aimed more at features that have been deprecated and eventually removed 🤔

Pinging the experts @florent-leborgne @shainaraskas @colleenmcginnis who will have more ideas about the appropriate pattern to use here.

nicer than a ::::{note} which highlights this whole paragraph as if it's important.

Yes, I think we could just remove the note too and that might suffice here, as the new behavior now has the applies_to tag

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that just pulling this out of a note would work. I think until we have ranges (eta 9.3), that's the best choice

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks. I removed the note annotation as suggested fb4b24a

Copy link
Contributor

@leemthompo leemthompo left a comment

Choose a reason for hiding this comment

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

Thanks for iterating on the docs!

@ywangd ywangd added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Dec 8, 2025
@elasticsearchmachine
Copy link
Collaborator

Hi @ywangd, I've updated the changelog YAML for you.

@elasticsearchmachine elasticsearchmachine merged commit 92750be into elastic:main Dec 8, 2025
40 checks passed
@ywangd ywangd deleted the index-exclusion-bug-fix branch December 8, 2025 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) >bug :Security/Security Security issues without another label Team:Security Meta label for security team v9.3.0

9 participants