fix(cloudwatch): retain metric-math alarm query definitions (#4594) #6

2026-10-25T03:08:32Z

Zakaria commented

2026-10-25 03:08:32 +00:00

No description provided.

Zakaria added 9 commits 2026-10-25 03:08:32 +00:00

fix(cloudwatch): retain metric-math alarm query definitions (#4594 ) cbb95ba26c

* fix(cloudwatch): retain metric-math alarm query definitions

* test(cloudwatch): use shared XML parser for alarm assertions

(cherry picked from commit 1d646c6fea70a8d4bfeea4d0ca6d8fc390ea6170)

fix(cloudwatch): raise ResourceNotFoundException when a tag operation names a resource that does not exist (#4783 ) ccdf32335d

* fix(cloudwatch): raise ResourceNotFoundException when a tag operation names a resource that does not exist

TagResource, UntagResource and ListTagsForResource answered 200 for any ARN, so
tagging a typo'd or deleted alarm, dashboard or metric stream told the caller the
tag had been applied. AWS raises ResourceNotFoundException. All three operations
now resolve the ARN first and report a 404 when nothing answers to it.

The fix sits in the three services rather than in the handlers, because CloudWatch
Metrics serves these operations over both Query and JSON 1.1 and the two handlers
route to the same service methods. A handler-level check would have left the other
protocol still answering 200.

What the 200 was hiding is worth naming, because "return an error instead of 200"
understates it. The write path resolved the ARN and then did nothing with the miss:
tagResource and untagResource each ended in an ifPresent, so a tag against an
unknown ARN was discarded, and ListTagsForResource answered the empty map. So the
ARN was neither rejected nor recorded. Nothing was stored against a phantom
resource, which is the one mercy here, but a caller that wrote a tag and read back
an empty list had no way to tell "this resource has no tags" from "this resource
does not exist".

That is why ListTagsForResource is included rather than left alone. It is the one
operation whose answer changes for a caller doing a speculative list, and the one
whose leniency made the silent write survive a round trip. No test or caller in the
repository depended on the empty-map answer for an unknown ARN: the only internal
caller is CloudWatchDashboardCfnProvisioner.reconcileTags, and both of its call
sites pass an ARN that putDashboard has just returned.

The error code is ResourceNotFoundException, not the shorter ResourceNotFound that
GetDashboard, DeleteDashboards and SetAlarmState answer with. Those are two separate
shapes in the CloudWatch model, mapped to two exception classes by the SDK, and the
model declares the longer one on exactly these three operations.

CloudWatch Logs needed no change. Its own TagResource, UntagResource and
ListTagsForResource already resolve the log group and raise
ResourceNotFoundException, which the new test pins so the two halves of CloudWatch
tagging cannot diverge in the other direction.

* fix(cloudwatch): resolve a dashboard by either the regionless or the region-ful form of its ARN

Dashboards are a global resource and AWS documents their ARN without a region,
arn:aws:cloudwatch::<account-id>:dashboard/<dashboard-name>, on both the TagResource
and the ListTagsForResource pages. Floci mints a region-ful one. The dashboard
lookup now accepts both shapes deliberately, so a caller holding either resolves.

Accepting both is what stops the preceding commit regressing a caller that does the
documented thing. Until the tag operations raised on a miss, the divergence was
invisible on this path: the documented ARN matched no stored dashboard, and the
answer was a silent 200 with an empty tag map. Turning a miss into
ResourceNotFoundException would have turned that into a hard 404 for a dashboard
that exists.

Only an absent region stands in for the dashboard's own, so an ARN naming some other
region is still a miss and does not resolve to a same-named dashboard here.

What Floci mints is not changed. Clients may already hold the ARNs it has handed
out, so bringing the minted shape into line with AWS alters values already in
circulation and belongs in its own change; it is tracked separately. The tolerant
lookup is all that is needed to keep this path correct, and it is strictly more
permissive than before, so it cannot break a caller that works today.

Alarms and metric streams were checked rather than assumed: both mint region-ful
ARNs and AWS documents both region-ful, so the question is dashboards only.

Also reworded the not-found message on the alarm path to name the ARN that did not
resolve instead of asserting it was an alarm. Both tag handlers route every ARN that
is not a dashboard and not a metric stream to that path, including kinds AWS
considers taggable and Floci does not serve, a Contributor Insights insight-rule ARN
being the one AWS documents. Reporting that no resource matches the ARN is true of
those; "alarm not found" was not. No Contributor Insights support is added here.

* test(cloudwatch): assert a refused tag call left the real resource untagged

The not-found tests tagged the unknown ARN env=prod and then re-tagged the real
resource env=dev before reading it back, so a failed call that had written through
to the real resource would have been overwritten and the assertion would still
pass. Read the real resource's tags first; they must be empty.

* test(cloudwatch): import matchers and use configureAwsContentTypes

Import Matchers.not and java.util.Map in the new tests instead of writing
them inline, register the x-amz-json content types through
RestAssuredJsonUtils.configureAwsContentTypes() in place of registerParser
and the hand-built encoder config, and drop DeleteDashboards from the
requireDashboard Javadoc: only GetDashboard declares ResourceNotFound.

(cherry picked from commit 0c8d1848541392ff91991121d96586db564cb3f8)

fix(cloudwatch): publish SNS actions on alarm state transitions (#5918 ) 2e0a438d70

(cherry picked from commit f5811c3a0735be634b6122503237330826e0ba4a)

fix(cloudwatch): store datums sent in PutMetricData EntityMetricData (#6070 ) 21625c5a1b

The CloudWatch Agent sends PutMetricData with an empty top-level
MetricData and every datum nested under EntityMetricData[].MetricData.
Both the JSON 1.0 handler (also reached by Smithy RPC v2 CBOR) and the
Query handler read only the top-level list, so the agent's metrics were
silently dropped.

Both handlers now append each EntityMetricData entry's datums to the
top-level ones and store them under the request Namespace, with the same
parsing as top-level datums. Entity and StrictEntityValidation are
accepted and ignored. The per-request INFO logs of the raw request and
parsed datums are lowered to a DEBUG count.

Fixes #6066

(cherry picked from commit 03f57303969561b049c3ebba38f1fd9d2b68df4c)

fix(cloudwatch): name the alarm's region without the partition catalog e90978ae94

The SNS alarm notification from upstream (#5918) looks up the region's display
name in AwsPartitions, which upstream added in a partition rework not taken
here. A table of the commercial regions' names gives the same Region field.

fix(cloudwatch): reject PutMetricData datums without a MetricName (#6072 ) 24314f4432

* fix(cloudwatch): reject PutMetricData datums without a MetricName

MetricName is the one required member of MetricDatum. The JSON handler
stored a nameless datum under an empty name, and the Query handler
treated a member without MetricName as the end of the list, silently
dropping it and every later datum while still storing the earlier ones.

Both handlers now reject a missing or empty MetricName in top-level
MetricData and in EntityMetricData[].MetricData with MissingParameter
(400), the error PutMetricData declares for a missing required input,
naming the offending member. A whitespace name is still accepted, since
AWS constrains MetricName only to 1 to 255 characters. Every datum is
validated before any is stored, so a rejected request leaves no state
behind. On Query, a member index with no keys at all still ends that
MetricData list.

* fix(cloudwatch): return MissingRequiredParameterException on JSON and CBOR

CloudWatch is awsQueryCompatible. MissingParameter is the awsQueryError
code of the MissingRequiredParameterException shape, so it belongs in the
Query <Code> and the x-amzn-query-error header, while a JSON 1.0 or CBOR
body's __type names the shape. With the code in __type the AWS SDK v2
raised a generic CloudWatchException instead of the modelled one.

A package-private CloudWatchMetricsException keeps the Query code as its
error code and overrides jsonType() with the shape name, the same split
SwfException makes. The shared query-code table in AwsException is left
alone because SQS reports MissingParameter as its JSON type.

(cherry picked from commit b8d87df05413ea8c4f9497fa05f388c19d4124ec)

fix(cloudwatch): return empty CompositeAlarms and LogAlarms from DescribeAlarms (#6363 ) 83aafc0325

* fix(cloudwatch): return empty CompositeAlarms and LogAlarms from DescribeAlarms

AWS sends every alarm collection even when it is empty. Floci only sent
MetricAlarms, so the AWS CLI's text output printed a leading None line
for each missing paginator result key.

Closes #6362

* test(cloudwatch): check empty alarm collections in sdk-test-python instead of bats

Drop the new AWS CLI bats file and assert the empty CompositeAlarms and
LogAlarms lists in the existing describe_alarms test, as boto3 leaves an
absent list out of the response.

(cherry picked from commit 42f5019231b446c727d6c94def9d1445263de2d7)

feat(cloudwatch): support composite alarm lifecycle (#6408 ) fa3327bf71

(cherry picked from commit 922e36a472341861e97d1b5639656f3c4a3978d8)

chore: add the upstream helpers the composite alarm change builds on a9df81a294

Composite alarms from upstream (#6408) use SmithyValidationErrors for AWS's
validation messages, and their tests use the CfnStackWaits, PartitionCleanup
and ThreadStates test helpers and ReplacementCleanup.owedPhysicalIds. These
are copied from upstream as they were at that commit; none brings in other
behaviour.

Zakaria merged commit 607ac0803b into main

2026-10-25 03:08:55 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Zakaria/FlociClone#6