Repository navigation
fix(data_classes): return None from CloudWatchAlarmMetric.metric_stat for expression entries - #8691
Conversation
… for expression entries `metric_stat` read `self["metricStat"]` directly, so it raised `KeyError` on the expression entries of a metric math alarm. `expression` and `label` in the same class already use `self.get(...)` for optional keys; this makes `metric_stat` consistent with them. The repository's own `cloudWatchAlarmEventSingleMetric.json` fixture has this shape — its first metric (`e1`, `expression: "m1/m2"`) has no `metricStat` — so the new test reproduces it without any synthetic payload. Signed-off-by: ShussMiao <168898188+ShussMiao@users.noreply.github.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #8691 +/- ##
========================================
Coverage 96.95% 96.95%
========================================
Files 321 321
Lines 16253 16254 +1
Branches 1453 1453
========================================
+ Hits 15758 15759 +1
Misses 353 353
Partials 142 142 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
leandrodamascena
left a comment
There was a problem hiding this comment.
Thanks @ShussMiao, and welcome. I did not stop at the fixture: I created a real metric math alarm with a Lambda action, forced it into ALARM, and the event CloudWatch delivered has the expression entry without metricStat, exactly like the fixture. With your change the loop over metrics works and the two real metrics still resolve. Returning None keeps metric_stat consistent with expression and label. Approving, this goes out in 3.39.0, no rebase needed, and you'll be credited in the release notes.



Issue number: closes #8673
Summary
Changes
CloudWatchAlarmMetric.metric_statreadself["metricStat"]directly, so it raisedKeyError: 'metricStat'on the expression entries of a metric math alarm.expressionandlabelin the same class already useself.get(...)for optional keys, so this makesmetric_statconsistent with them and widens the return type toCloudWatchAlarmMetricStat | None.The added test uses the repository's existing
cloudWatchAlarmEventSingleMetric.jsonfixture — its first metric (e1,expression: "m1/m2") has nometricStat— so no synthetic payload is needed.Note on triage: this issue is not labelled
triageyet, so flagging it here. The failure is reproducible from the repo's own event fixture with no AWS access, andorigin/developstill readsself["metricStat"]at line 94 of the file.User experience
Looping over
alarm_data.configuration.metricsand readingmetric_statnow works for metric math alarms instead of failing on the first expression entry.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.