fix(cloudwatch): render region and accountId when directly set on metrics

[TrevorBurnham]

Issue

Closes #28731

Reason for this change

Currently, if a user creates a metric that includes region and accountId, those fields are omitted when the metric renders in a stack with those same values. The intended behavior is to omit those fields when they're implicitly set via metric.attachTo(stack), not to omit them when set directly by the user.

Description of changes

This is a second attempt at #29935, which was auto-closed after the pull request linter complained that there were no integration test changes. This time around I've tried to satisfy the linter. Otherwise, the changes are the same as before:

The key changes here are on the Metric class. Previously, region and account were public properties that were set by metric.attachTo(stack), making it impossible to differentiate whether they were set directly or via attachTo. To differentiate them while maintaining backward compatibility, I took this approach:

1. attachTo sets internal properties called stackRegion and stackAccount. Setting region and account directly sets internal properties called regionOverride and accountOverride.
2. The public region and account properties are now getters that return the override (if set) and fall back on the stack properties.
3. The toMetricConfig() method returns the region and account from the getters, but also includes the regionOverride and accountOverride.

That way, everything that looks at region and account works the same way it did before, except in metricGraphJson, which skips the "if different from stack" tokenization if the overrides are set.

Description of how you validated changes

1. Confirmed that all existing unit tests pass.
2. Added a new unit test to show that region and account are now preserved when set directly on a metric.
3. Modified an integration test to show how setting region and account on a metric affects the snapshot.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[TrevorBurnham]

I don't know what's going on in the build log. It says:

Failed tasks:

- aws-cdk-lib:test
...
�  Last command failed. Scroll up to see errors in log (search for '!!!!!!!!').

But there are no matches for !!!!!!!! anywhere else in the log. 😕

[aws-cdk-automation]

This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

[TrevorBurnham]

I tried again, but the build is still failing. It's very strange; the build log says:

Failed tasks:

- aws-cdk-lib:test

But the output for aws-cdk-lib:test is:

> aws-cdk-lib:test

@aws-cdk/region-info: �[2K�[1G@aws-cdk/region-info: �[1myarn run v1.22.22�[22m
aws-cdk-lib: �[2K�[1Gaws-cdk-lib: �[1myarn run v1.22.22�[22m
@aws-cdk/region-info: �[2K�[1G�[2m$ yarn gen && cdk-build --skip-lint�[22m
aws-cdk-lib: �[2K�[1G�[2m$ jest�[22m
@aws-cdk/region-info: �[2K�[1G@aws-cdk/region-info: �[2m$ cdk-copy region-info�[22m
@aws-cdk/region-info: Build times for @aws-cdk/region-info: Total time (7.7s) | /codebuild/output/src2453208760/src/github.com/aws/aws-cdk/node_modules/jsii/bin/jsii (7.5s) | cdk-copy region-info (0.1s)
@aws-cdk/region-info: �[2K�[1GDone in 8.24s.

[gracelu0]

@TrevorBurnham Looking at the build logs I believe some unit tests need to be updated, e.g.

aws-cdk-lib: FAIL aws-rds/test/cluster.test.ts (24.426 s)
aws-cdk-lib:   � cluster › cluster supports metrics
aws-cdk-lib:     expect(received).toEqual(expected) // deep equality
aws-cdk-lib:     - Expected  - 4
aws-cdk-lib:     + Received  + 4
aws-cdk-lib:       Object {
aws-cdk-lib:     -   "account": "12345",
aws-cdk-lib:         "dimensions": Object {
aws-cdk-lib:           "DBClusterIdentifier": Object {
aws-cdk-lib:             "Ref": "DatabaseB269D8BB",
aws-cdk-lib:           },
aws-cdk-lib:         },
aws-cdk-lib:         "metricName": "CPUUtilization",
aws-cdk-lib:         "namespace": "AWS/RDS",
aws-cdk-lib:     -   "period": Duration {
aws-cdk-lib:     +   "period": Object {
aws-cdk-lib:           "amount": 5,
aws-cdk-lib:     -     "unit": TimeUnit {
aws-cdk-lib:     +     "unit": Object {
aws-cdk-lib:             "inMillis": 60000,
aws-cdk-lib:             "isoLabel": "M",
aws-cdk-lib:             "label": "minutes",
aws-cdk-lib:           },
aws-cdk-lib:         },
aws-cdk-lib:     -   "region": "us-test-1",
aws-cdk-lib:     +   "stackAccount": "12345",
aws-cdk-lib:     +   "stackRegion": "us-test-1",
aws-cdk-lib:         "statistic": "Average",
aws-cdk-lib:       }
aws-cdk-lib:       2732 |     });
aws-cdk-lib:       2733 |
aws-cdk-lib:     > 2734 |     expect(stack.resolve(cluster.metricCPUUtilization())).toEqual({
aws-cdk-lib:            |                                                           ^
aws-cdk-lib:       2735 |       dimensions: { DBClusterIdentifier: { Ref: 'DatabaseB269D8BB' } },
aws-cdk-lib:       2736 |       namespace: 'AWS/RDS',
aws-cdk-lib:       2737 |       metricName: 'CPUUtilization',
aws-cdk-lib:       at Object.<anonymous> (aws-rds/test/cluster.test.ts:2734:59)

You can search for FAIL to find the failing unit tests

[TrevorBurnham]

@gracelu0 Thanks for pointing me in the right direction! I figured out the issue:

1. The new public getters were not enumerable, and
2. The new private fields were enumerable.

This caused backward compatibility-breaking behavior that showed up in those unit tests. I've corrected this by explicitly making the getters enumerable using Object.defineProperty, and switching the new private fields over to from the private keyword to the new #privateField syntax. I've added a new unit test to cover those specific aspects of Metric's behavior.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.52%. Comparing base (bbdd42c) to head (2518dad).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #32325   +/-   ##
=======================================
  Coverage   81.52%   81.52%           
=======================================
  Files         222      222           
  Lines       13715    13715           
  Branches     2417     2417           
=======================================
  Hits        11181    11181           
  Misses       2254     2254           
  Partials      280      280           

Flag	Coverage Δ
suite.unit	81.52% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	80.97% <ø> (ø)
packages/aws-cdk-lib/core	82.09% <ø> (ø)

[xazhao]

Why do we need to stackAccount and stackRegion here? Can we directly set region and account?

[xazhao]

making it impossible to differentiate whether they were set directly or via attachTo

Do we need to differentiate whether they're set directly or via attachTo?

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 2518dad
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[TrevorBurnham]

Do we need to differentiate whether they're set directly or via attachTo?

The intent is to fix #28731 while preserving as much of the existing behavior as possible. The background facts are:

• Currently, account/region values that match those of the stack are excluded from serialization, regardless of whether those values are set directly by the user or implicitly via attachTo.
• Excluding values set directly by the user is a bug.

That means there are two possible solutions:

1. Differentiate whether the account/region values were set directly or via attachTo, or
2. Always include account/region values in serialization, regardless of how they were set.

This PR takes the first approach in order to maximize backward compatibility: Users who aren't directly setting account/region values won't see any change in serialized output. The second approach would make for a simpler code change, but a large number of users would see their serialized output change.

[xazhao]

Do we need to differentiate whether they're set directly or via attachTo?

The intent is to fix #28731 while preserving as much of the existing behavior as possible. The background facts are:

• Currently, account/region values that match those of the stack are excluded from serialization, regardless of whether those values are set directly by the user or implicitly via attachTo.
• Excluding values set directly by the user is a bug.

That means there are two possible solutions:

1. Differentiate whether the account/region values were set directly or via attachTo, or
2. Always include account/region values in serialization, regardless of how they were set.

This PR takes the first approach in order to maximize backward compatibility: Users who aren't directly setting account/region values won't see any change in serialized output. The second approach would make for a simpler code change, but a large number of users would see their serialized output change.

Got it. Thanks for the explanations. Approved.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.