Repository navigation
Conversation
0507afc to
e0df1b5
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD — period rollover is inferred from a value decrease, so a restarted period whose first observed usage is equal to or above the prior value is not fully re-armed. For example, with a prior value of 15 and thresholds at 10/20, a new-period value of 25 reports only 20 instead of both thresholds. Distinguish resetting usage from carry-over usage without relying on |
e0df1b5 to
5c59654
Compare
5c59654 to
48894c8
Compare
48894c8 to
d5fa801
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD: period rollover is inferred from The same heuristic misclassifies a cumulative recurring metric that legitimately decreases after the boundary and can re-fire thresholds as though it reset. Determine rollover from the monitored metric's reset semantics and add tests for both cases. |
8d43e68 to
6c8b131
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD: Recovery notifications are skipped at every period boundary, even when |
6c8b131 to
c14163a
Compare
c14163a to
8bb3d5f
Compare
8bb3d5f to
91a0c8e
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD — the rollover behavior is not covered for non-recurring billable-metric alerts.
|
91a0c8e to
25a0d7c
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — Period rebasing is correctly limited to resetting current-usage windows, preserves recurring and lifetime baselines, suppresses false boundary recoveries, and has focused coverage for each affected alert type. The targeted spec could not be executed here because the required |
25a0d7c to
798ba14
Compare
798ba14 to
641a422
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — Period rollover now re-baselines only period-scoped current-usage alerts, while preserving recurring and lifetime windows and avoiding false recovery records. Coverage exercises total and per-metric amount/units alerts, recurring metrics, threshold refiring, and recovery behavior. The targeted spec could not be run locally because the required |
641a422 to
601d27f
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — The rollover rebaseline is scoped to resettable current-usage windows, preserves recurring and lifetime baselines, and focused specs cover threshold refiring and recovery behavior. |
601d27f to
9702465
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD — A billable-metric alert can permanently miss the renewal rebaseline when the metric is absent from the plan on the first evaluation. |
9702465 to
491d1c0
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — The period rollover logic is correctly scoped to current-usage alerts, preserves continuous recurring-metric baselines, suppresses false boundary recoveries, and has focused coverage across total, per-metric, units, recurring, and lifetime cases. |
491d1c0 to
6a5c5b3
Compare
6a5c5b3 to
08d6c19
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — The period rollover logic is consistent across current-usage alert variants, preserves recurring and lifetime windows, and has focused coverage for re-triggering, resolution suppression, and recurring-metric exceptions. |
08d6c19 to
b6d5bac
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — Period rollover handling is consistent across all current-usage alert types, preserves recurring and lifetime baselines, and avoids false recovery events. The added specs cover reset and non-reset paths for total amount and metric-specific amount/units alerts. |
b6d5bac to
3932c6a
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD: Mixed recurring/non-recurring plans are mishandled because one recurring charge disables rollover rebasing for the entire current-usage total; the non-recurring portion can reset below a threshold and cross it again without an alert. Handle the mixed-plan baseline correctly and add a regression test containing both recurring and non-recurring charges. |
3932c6a to
cd04ca4
Compare
|
Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green HOLD — a billable-metric alert can consume the period rollover without resetting its baseline. When |
cd04ca4 to
df85049
Compare
|
Automated pre-review (advisory, not a required check) — verdict: PASS · CI green PASS — The rollover logic re-baselines period-scoped current-usage alerts while preserving recurring and lifetime baselines, and it avoids emitting a false recovery at the boundary. The specs cover total amount, metric amount and units, recurring metrics, and lifetime usage; no blocking sibling-site or safety issue is apparent. |
At renewal, usage starts again from nothing. To an alert that compares against the last value it saw, that looks like every threshold clearing at once, which would announce a recovery for every affected customer at the same moment. The same comparison hides a second problem that exists today. An evaluation early in a new period compares the small new usage against the large figure carried over from the last one, finds nothing crossed, and stores the small figure. A threshold the customer really did cross in those first moments is never reported. Product approved fixing this in the knowledge that previously silent alerts will start firing. When the last evaluation belongs to an earlier period, the comparison starts from nothing instead. The boundary then reads as usage climbing from zero, which reports whatever the new period has already passed and cannot read as a recovery. So the storm never happens, and the alerts that used to be swallowed arrive. This applies only to alerts that watch usage within a period. Alerts counting lifetime usage are deliberately excluded: that figure accumulates across periods by design, so starting from nothing would recompute the whole history as newly crossed and re-report every threshold at every boundary, forever, for exactly the customers using them. They keep comparing against the value they stored, which is correct for them, and the swallowed-alert problem does not arise there either. A test covers two consecutive boundaries to hold that line. Excluding lifetime alerts by type is not enough on its own, because a recurring billable metric aggregates from the start of the subscription rather than from the period, so its usage does not restart either even though the alert watches current usage. Rather than enumerate which metrics behave that way, the baseline is only cleared when the measured value actually fell, which is what a genuine restart looks like. Usage that carried across the boundary keeps its baseline and is compared normally, so nothing is re-reported. A test covers two consecutive boundaries for that case too.
df85049 to
db48b4f
Compare
2 participants
Context
At renewal, usage starts again from nothing. To an alert that compares against the last value it saw, that looks like every threshold clearing at once. The same comparison hides a second problem that exists today: an evaluation early in a new period compares small new usage against the large figure carried over, finds nothing crossed, and stores the small figure, so a threshold the customer really did cross in those first moments is never reported.
Changes
When the last evaluation belongs to an earlier period, the comparison starts from nothing instead. The boundary then reads as usage climbing from zero, which reports whatever the new period has already passed and cannot read as a recovery.
Alerts counting lifetime usage are excluded, because that figure accumulates across periods by design.
Excluding them by type is not enough on its own: a recurring billable metric aggregates from the start of the subscription rather than from the period, so its usage does not restart either even though the alert watches current usage. Rather than enumerate which metrics behave that way, the baseline is only cleared when the measured value actually fell, which is what a genuine restart looks like. Usage that carried across the boundary keeps its baseline and is compared normally, so nothing is re-reported. Tests cover two consecutive boundaries for both cases.