marshallmain
commented
1 year ago To minimize breaking changes now and in the future, we could copy the validation logic that the alerting framework uses: either the rule level frequency can be used or frequencies can be set on individual actions, but frequencies can not be specified at both levels simultaneously in a request. We could leave the throttle and notifyWhen settings where they are in the schema but not allow them to be set when the new action-level frequencies are used.
Copied from slack:
the code we have will work for converting from rule + action level frequencies into just action level frequencies, but the potential problem is that we are allowing API users to use the rule level frequency as a default setting whereas alerting does not allow that. If we wanted to consolidate the APIs (possibly remove our API and just redirect to the alerting APIs) in the future we might have to remove the ability to use the rule level setting as a default which would be another breaking change for users that used it that way. If our API never allows both together then we won't have to risk a breaking change by taking away that ability in the future. But, we can still remove the restriction in the future at any point if it becomes necessary.
elasticmachine
yctercero
banderror
Post https://github.com/elastic/kibana/pull/154990 updates:
As part of these changes we realised that we don't really need
throttleattribute in rule schema. See comments from @maximpn and @banderror here. We should remove it from here and adjust the rest of the code accordingly.We should also remove
throttleandnotifyWhenfromInternalRuleCreateandInternalRuleUpdaterule schema here. See this comment.