-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[CI] WatcherConcreteIndexTests testCanUseAnyConcreteIndexName failure #50658
Comments
Pinging @elastic/es-core-features (:Core/Features/Watcher) |
This failed because the watch didn't trigger, which was caused by the fact that the scheduler was paused:
The reason the scheduler was paused:
|
This test replaces the watch index after watcher got started. This triggers watches being reloaded and while this happens the trigger engine is paused, which disallows watches from being triggered. At this time there are no watches in the .watches index and I think this is just unlucky timing. Reloading of watches happens in the background and the watch state can be started when that happens. For normal schedule trigger engines this is not an issue, because watches that are meant to be triggered are triggered when the engine triggers the next time. However for the mock scheduled trigger engine this is different, because watches are triggered programatically and there is no retry in this. I think just adding |
This test replaces the watch index after watcher got started. This triggers watches being reloaded and while this happens the trigger engine is paused, which disallows watches from being triggered. At this time there are no watches in the .watches index and I think this is just unlucky timing. Reloading of watches happens in the background and the watch state can be started when that happens. For normal schedule trigger engines this is not an issue, because watches that are meant to be triggered are triggered when the engine triggers the next time. However for the mock scheduled trigger engine this is different, because watches are triggered programatically and there is no retry in this test. I think just adding `timeWarp().trigger("mywatch");` inside a `assertBusy(...)`` is the right fix here. If it fails because the mock schedule trigger engine is paused then the test will try again. In the mean time the the watches can be reloaded, which then resumes the mock scheduled trigger engine. Closes #50658
This test replaces the watch index after watcher got started. This triggers watches being reloaded and while this happens the trigger engine is paused, which disallows watches from being triggered. At this time there are no watches in the .watches index and I think this is just unlucky timing. Reloading of watches happens in the background and the watch state can be started when that happens. For normal schedule trigger engines this is not an issue, because watches that are meant to be triggered are triggered when the engine triggers the next time. However for the mock scheduled trigger engine this is different, because watches are triggered programatically and there is no retry in this test. I think just adding `timeWarp().trigger("mywatch");` inside a `assertBusy(...)`` is the right fix here. If it fails because the mock schedule trigger engine is paused then the test will try again. In the mean time the the watches can be reloaded, which then resumes the mock scheduled trigger engine. Closes #50658
This test replaces the watch index after watcher got started. This triggers watches being reloaded and while this happens the trigger engine is paused, which disallows watches from being triggered. At this time there are no watches in the .watches index and I think this is just unlucky timing. Reloading of watches happens in the background and the watch state can be started when that happens. For normal schedule trigger engines this is not an issue, because watches that are meant to be triggered are triggered when the engine triggers the next time. However for the mock scheduled trigger engine this is different, because watches are triggered programatically and there is no retry in this test. I think just adding `timeWarp().trigger("mywatch");` inside a `assertBusy(...)`` is the right fix here. If it fails because the mock schedule trigger engine is paused then the test will try again. In the mean time the the watches can be reloaded, which then resumes the mock scheduled trigger engine. Closes #50658
This test replaces the watch index after watcher got started. This triggers watches being reloaded and while this happens the trigger engine is paused, which disallows watches from being triggered. At this time there are no watches in the .watches index and I think this is just unlucky timing. Reloading of watches happens in the background and the watch state can be started when that happens. For normal schedule trigger engines this is not an issue, because watches that are meant to be triggered are triggered when the engine triggers the next time. However for the mock scheduled trigger engine this is different, because watches are triggered programatically and there is no retry in this test. I think just adding `timeWarp().trigger("mywatch");` inside a `assertBusy(...)`` is the right fix here. If it fails because the mock schedule trigger engine is paused then the test will try again. In the mean time the the watches can be reloaded, which then resumes the mock scheduled trigger engine. Closes elastic#50658
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+release-tests/760/console
https://gradle-enterprise.elastic.co/s/eaphkxcjw4fea
Does not reproduce:
The text was updated successfully, but these errors were encountered: