fix(multilocation_alert_condition): make violation_time_limit_seconds nearly consistent with its usage in nrql_alert_condition #2493
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.
As reported in #2475, the current validation against the argument
violation_time_limit_seconds
does not allow using the value259200
(30 days), while this is supposed to be allowed as per New Relic's docs.This attribute
violation_time_limit_seconds
is also used innewrelic_nrql_alert_condition
to serve the same usecase, but it appears that the validation and other schema specifications are not the same in both of these resources. This PR aims at correcting the above.Additionally, since
0
has been permitted to be valid value of theviolation_time_limit_seconds
argument so far (though values ofviolation_time_limit_seconds
are expected to ∈ [300, 2592000] like specified withnewrelic_nrql_alert_condition
), aDiffSuppressFunc
has been added toviolation_time_limit_seconds
in themultilocation_alert_condition
resource to handle the case in which users specify 0, but the API defaults 0 to 259200 (3 days), and hence, differences need to be suppressed.