Remove unstable Assertion in IndexMetadataUpdater#applyChanges (#86159) #87649
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ic#86159) This assertion here isn't stable unfortunately even though it would be nice to assert this. The problem is that the same cluster state instance that is updated here might be concurrently used and the index lookup could have been created in it while we update index metadata (from all kinds of actions that set it up). I don't see a way to stabilize it that would actually be safe since the index lookup is cached in `Metadata` on a best effort basis and we can't read the field on an instance of `Metadata` in a manner that would deterministically that a subsequent read returns the same value. -> removing the assertion closes elastic#86090
original-brownbear
added
:Data Management/Indices APIs
elasticmachine
added
the
Team:Data Management
|
Pinging @elastic/es-data-management (Team:Data Management) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This assertion here isn't stable unfortunately even though it would be nice to assert this. The problem is that the same cluster
state instance that is updated here might be concurrently used and the index lookup could have been created in it while we update
index metadata (from all kinds of actions that set it up).
I don't see a way to stabilize it that would actually be safe since the index lookup is cached in
Metadataon a best effort basisand we can't read the field on an instance of
Metadatain a manner that would deterministically that a subsequent readreturns the same value.
-> removing the assertion
closes #86090
backport of #86159