-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datastream unavailable exception metadata #91461
Datastream unavailable exception metadata #91461
Conversation
@elasticmachine run elasticsearch-ci/part-1 |
if (options.ignoreUnavailable() == false) { | ||
ensureAliasOrIndexExists(context, expression); | ||
} | ||
IndexAbstraction indexAbstraction = indicesLookup.get(expression); | ||
if (indexAbstraction == null) { | ||
if (options.ignoreUnavailable() == false) { | ||
assert options.expandWildcardExpressions() == false; | ||
throw notFoundException(expression); | ||
} else { | ||
continue; | ||
} | ||
continue; | ||
} else if (indexAbstraction.getType() == Type.ALIAS && context.getOptions().ignoreAliases()) { | ||
if (options.ignoreUnavailable() == false) { | ||
assert options.expandWildcardExpressions() == false; | ||
throw aliasesNotSupportedException(expression); | ||
} else { | ||
continue; | ||
} | ||
continue; | ||
} else if (indexAbstraction.isDataStreamRelated() && context.includeDataStreams() == false) { | ||
excludedDataStreams = true; | ||
continue; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of this is going to be moved, in a follow-up PR, inside the resolveExpression
method on line 339.
Pinging @elastic/es-core-infra (Team:Core/Infra) |
This sounds good to me. I can't find anyone referring to |
No, I can't find references to it (it eventually gets serialized in the exception body of the response as |
@swallez confirmed on another channel that client code doesn't look at exception metadata fields. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Can you add the bug label to the PR ? I think at least the first commit fixes a bug and the second one is arguable a bug too.
Hi @albertzaharovits, I've created a changelog YAML for you. |
@elasticsearchmachine update branch |
* main: (163 commits) [DOCS] Edits frequent items aggregation (elastic#91564) Handle providers of optional services in ubermodule classloader (elastic#91217) Add `exportDockerImages` lifecycle task for exporting docker tarballs (elastic#91571) Fix CSV dependency report output file location in DRA CI job Fix variable placeholder for Strings.format calls (elastic#91531) Fix output dir creation in ConcatFileTask (elastic#91568) Fix declaration of dependencies in DRA snapshots CI job (elastic#91569) Upgrade Gradle Enterprise plugin to 3.11.4 (elastic#91435) Ingest DateProcessor (small) speedup, optimize collections code in DateFormatter.forPattern (elastic#91521) Fix inter project handling of generateDependenciesReport (elastic#91555) [Synthetics] Add synthetics-* read to fleet-server (elastic#91391) [ML] Copy more settings when creating DF analytics destination index (elastic#91546) Reduce CartesianCentroidIT flakiness (elastic#91553) Propagate last node to reinitialized routing tables (elastic#91549) Forecast write load during rollovers (elastic#91425) [DOCS] Warn about potential overhead of named queries (elastic#91512) Datastream unavailable exception metadata (elastic#91461) Generate docker images and dependency report in DRA ci job (elastic#91545) Support cartesian_bounds aggregation on point and shape (elastic#91298) Add support for EQL samples queries (elastic#91312) ... # Conflicts: # x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/downsample/RollupShardIndexer.java
The goal of this PR is to reuse the "resource unavailable" exception conditions,
between when wildcards are expanded and when they're not.
It's a (big) step in that direction, rather than a complete work.
I have stopped short of a complete implementation because
I became aware of a required behavior change that I think needs
analyzed and discussed in advance, so that I can confidently proceed.
I'll explain commit-by-commit:
19a4128 When wildcards are expanded, explicitly naming datastreams when the context disallows datastreams, and also when
ignore_unavailable
isfalse
, will generate a "not found" exception, see:elasticsearch/server/src/main/java/org/elasticsearch/cluster/metadata/IndexNameExpressionResolver.java
Line 1274 in 6e60e6a
However, in the same context that doesn't allow datastreams, but without expanding wildcards, datastreams are always ignored, even if
ignore_unavailable
isfalse
. This commit fixes that.938d2c0 Is the behavior change that I think needs to be discussed. Some "index not found" exceptions have a metadata field
es.excluded_ds: true
. The field is only used in a single place, and only for update requests (which don't support datastreams, and only target a single index):elasticsearch/server/src/main/java/org/elasticsearch/action/support/single/instance/TransportInstanceSingleOperationAction.java
Line 146 in d5b4584
ignore_unavailable
istrue
or because, as described above (and fixed), datastreams are always ignored when wildcards are not expanded).ignore_unavailable
isfalse
.ignore_unavailable
isfalse
), but the metadata field is visible to callers.d1f11d4 Reuses the method that generates "not found" exceptions. In this context I realised that for a single "unavailable" name, sometimes the exception was constructed with
infe.setResources("index_or_alias", expression);
and sometimes withinfe.setResources("index_expression", expression);
; I opted to always useindex_or_alias
.6b2dc8e This shows the direction I'm going to, I will iterate on it to encapsulate the handling of unavailable resources inside the
resolveExpressions
method.Is the slight behavior change (circumstances when the "not found" exceptions contain a metadata field, without impacting any other behaviors, but that can be observed by callers in the serialized exception, as detailed above) a concern for anybody?