Watcher: Prevent triggering watch when using activate API #30613
Conversation
This file contains hidden or 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
Collaborator
|
Pinging @elastic/es-core-infra |
A wrong check in the activate watch API could lead to watches triggering on wrong nodes. The check was supposed to check if watch execution was distributed already in 6.x and only if not, then trigger locally. The if-condition however was broken and triggered the watch only when distributed watch execution was actually enabled.
spinscale
force-pushed
the
1805-prevent-activate-watch-api-from-triggering-watches-on-wrong-nodes
branch
from
28f6c33 to
0440c4c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
A wrong check in the activate watch API could lead to watches triggering
on wrong nodes. The check was supposed to check if watch execution
was distributed already in 6.x and only if not, then trigger locally.
The check however was broken and triggered the watch only when
distributed watch execution was actually enabled.
Due to another check in the trigger schedule engine, this problem is already solved on 6.3 on all non-data nodes (like client nodes), as no trigger is started there. However this needs to be fixed when you connect to a different data node (different as in where the watcher shard that maintains this watch is not).