-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Watchers: configurable iteration cap #45169
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
Comments
Pinging @elastic/es-core-features |
@CameronNemo - I am curious to which action (and why) you want execute 10,000 actions for each watch ? |
index or webhook action. we have over 400 devices so the 100 limit simply does not cut it. |
1000 would probably be alright, but why was the limit placed at exactly 100 in the first place? was there a measurement of time took? |
@CameronNemo - thanks for the feedback. 100 was an arbitrary upper bound to prevent an accidental mis-configuration and flooding some poor downstream system. +1 to add a dynamic configuration option for this, with 100 as the default. |
Hi guys, I'd like to work on this if that's ok. |
@jbonn360 - all yours. Please target master and feel free to ping me for review. Also, I can handle the any back porting to next minor version(s). |
@jakelandis Cheers, will do |
Hi guys, I want to work on this if that's fine. Can you please help me to get started and understand the code base? |
@deXetrous - thanks for the offer, but @jbonn360 has already submitted a PR for this. |
The foreach functionality added in #41997 contains a constant cap of 100 on iterations. This makes it inconvenient to use with bucket aggregations, which offer a configurable cap, defaulting to 10,000 buckets. I propose a configuration directive
actions.<id>.max_iterations
that replaces the hardcoded 100 cap.The text was updated successfully, but these errors were encountered: