Skip to content
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

Merged

Conversation

albertzaharovits
Copy link
Contributor

@albertzaharovits albertzaharovits commented Nov 9, 2022

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 is false, will generate a "not found" exception, see:


    However, in the same context that doesn't allow datastreams, but without expanding wildcards, datastreams are always ignored, even if ignore_unavailable is false. 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):

    if (request.includeDataStreams() == false && e.getMetadataKeys().contains(EXCLUDED_DATA_STREAMS_KEY)) {
    . It is however serialized, so it is visible to callers.

    • Curently, the metadata field is attached when an expression evalutes to the empty concrete indices list, and at least a datastreams was ignored in the process (either because ignore_unavailable is true or because, as described above (and fixed), datastreams are always ignored when wildcards are not expanded).
    • The proposed PR will attach the metadata field whenever a datastream is explicitly named in a context that disallows datastreams and ignore_unavailable is false.
    • Both approaches are equivalent with respect to the internal usage of the field (used only in the context of the update request, that disallows datastreams, refers to a single shard, and ignore_unavailable is false), but the metadata field is visible to callers.
    • I want to introduce this change is because I want to separate the layers that 1) resolve an expression to a list of index, alias, and datastream names (which will be reused in Security), and 2) expand the elements of that list to concrete indices (which will remain in Core). I cannot achieve the separation if the layer that expands to concrete indices (2) has to know about ignored datastreams, which are handled in the other layer.
  • 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 with infe.setResources("index_expression", expression);; I opted to always use index_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?

@albertzaharovits
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-1

@albertzaharovits albertzaharovits self-assigned this Nov 9, 2022
Comment on lines +352 to 363
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;
}

Copy link
Contributor Author

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.

@albertzaharovits albertzaharovits added >non-issue :Core/Infra/Core Core issues without another label labels Nov 9, 2022
@albertzaharovits albertzaharovits requested review from jakelandis and grcevski and removed request for jakelandis November 9, 2022 16:02
@albertzaharovits albertzaharovits changed the title Datastream not found error Datastream unavailable exception metadata Nov 9, 2022
@albertzaharovits albertzaharovits marked this pull request as ready for review November 9, 2022 16:03
@elasticsearchmachine elasticsearchmachine added the Team:Core/Infra Meta label for core/infra team label Nov 9, 2022
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@grcevski
Copy link
Contributor

grcevski commented Nov 9, 2022

This sounds good to me. I can't find anyone referring to es.excluded_ds and it's not documented, I think we can safely say it was only for the internal use of our own transport action. Do you know if it's mentioned in any client specs? Again, I can't find it, but I just want to make sure I didn't miss a place.

@albertzaharovits
Copy link
Contributor Author

albertzaharovits commented Nov 10, 2022

Do you know if it's mentioned in any client specs? Again, I can't find it, but I just want to make sure I didn't miss a place.

No, I can't find references to it (it eventually gets serialized in the exception body of the response as excluded_ds). The rest specs that I'm aware of (rest-api-spec project) are not concerned with responses at all. In addition I know we shouldn't change the "shape" of responses, and I also believe we're even laxer with error response bodies (though I admit I'm not sure of specific guidelines). I have asked the lang clients team for advice.

@albertzaharovits
Copy link
Contributor Author

I have asked the lang clients team for advice.

@swallez confirmed on another channel that client code doesn't look at exception metadata fields.

Copy link
Contributor

@grcevski grcevski left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Contributor

@jakelandis jakelandis left a 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.

@elasticsearchmachine
Copy link
Collaborator

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

@albertzaharovits
Copy link
Contributor Author

@elasticsearchmachine update branch

@albertzaharovits albertzaharovits merged commit 6fc31d3 into elastic:main Nov 14, 2022
@albertzaharovits albertzaharovits deleted the datastream-not-found-error branch November 14, 2022 12:40
weizijun added a commit to weizijun/elasticsearch that referenced this pull request Nov 15, 2022
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Core/Infra/Core Core issues without another label Team:Core/Infra Meta label for core/infra team v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants