Skip to content

Conversation

@rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Nov 28, 2025

The default flag report (showing the unconfigured flags) was basing its entries on a different filter than the message that says "N flags are unconfigured". This is confusing.

Currently, init-ing a project and then upgrading to the latest library shows:

2 feature flags are not configured. Run 'cdk flags --unstable=flags' to learn more.

But then running that commands shows 15 flags:

$ cdk flags --unstable=flags
┌─────────────────────────────────────────────────────────────────────────────────────┬─────────────┬─────────┬───────────┐
│ Feature Flag Name                                                                   │ Recommended │ User    │ Effective │
├─────────────────────────────────────────────────────────────────────────────────────┼─────────────┼─────────┼───────────┤
│ Module: aws-cdk-lib                                                                 │             │         │           │
│   @aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId                            │ true        │ <unset> │ true      │
│   @aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021                         │ true        │ <unset> │ true      │
│   @aws-cdk/aws-ec2-alpha:useResourceIdForVpcV2Migration                             │ false       │ <unset> │ false     │
│   @aws-cdk/aws-ecs-patterns:uniqueTargetGroupId                                     │ true        │ <unset> │ false     │
│   @aws-cdk/aws-elasticloadbalancingv2:networkLoadBalancerWithSecurityGroupByDefault │ true        │ <unset> │ false     │
│   @aws-cdk/aws-lambda:recognizeVersionProps                                         │ true        │ <unset> │ true      │
│   @aws-cdk/aws-rds:lowercaseDbIdentifier                                            │ true        │ <unset> │ true      │
│   @aws-cdk/aws-stepfunctions-tasks:httpInvokeDynamicJsonPathEndpoint                │ true        │ <unset> │ true      │

...etc...

The reason is those 2 bits of code used different filtering. Specifically, the warning excluded flags for which the default value is equal to the recommended value (i.e., flags that don't need to be configured at all because the default value is good enough), while the table was looking strictly for "unconfigured" flags.

The default == recommended pattern crops up in a couple of situations:

  • Security-related fixes that we want to force on people, but want to give them a flag to back out of the changes if they really need to.
  • Flags that changed their default value in the most recent major version.
  • Flags that we've introduced at some point in the past, but have gone back on.

In this PR, make both bits of code use the same logic so discrepancies like these can't happen anymore. Also add a header to the table so it's clear what you're currently looking at.

Also in this PR: remove a dead flags.ts code, that had been fully refactored to other files but had accidentally been left in.


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

The default flag report (showing the unconfigured flags) was basing its
entries on a different filter than the message that says "N flags are
unconfigured". This is confusing.

Currently, init-ing a project and then upgrading to the latest library
shows:

```
2 feature flags are not configured. Run 'cdk flags --unstable=flags' to learn more.
```

But then running that commands shows 15 flags:

```
$ cdk flags --unstable=flags
┌─────────────────────────────────────────────────────────────────────────────────────┬─────────────┬─────────┬───────────┐
│ Feature Flag Name                                                                   │ Recommended │ User    │ Effective │
├─────────────────────────────────────────────────────────────────────────────────────┼─────────────┼─────────┼───────────┤
│ Module: aws-cdk-lib                                                                 │             │         │           │
│   @aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId                            │ true        │ <unset> │ true      │
│   @aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021                         │ true        │ <unset> │ true      │
│   @aws-cdk/aws-ec2-alpha:useResourceIdForVpcV2Migration                             │ false       │ <unset> │ false     │
│   @aws-cdk/aws-ecs-patterns:uniqueTargetGroupId                                     │ true        │ <unset> │ false     │
│   @aws-cdk/aws-elasticloadbalancingv2:networkLoadBalancerWithSecurityGroupByDefault │ true        │ <unset> │ false     │
│   @aws-cdk/aws-lambda:recognizeVersionProps                                         │ true        │ <unset> │ true      │
│   @aws-cdk/aws-rds:lowercaseDbIdentifier                                            │ true        │ <unset> │ true      │
│   @aws-cdk/aws-stepfunctions-tasks:httpInvokeDynamicJsonPathEndpoint                │ true        │ <unset> │ true      │

...etc...
```

The reason is those 2 bits of code used different filtering.
Specifically, the warning excluded flags for which the default value is
equal to the recommended value (i.e., flags that don't need to be
configured at all because the default value is good enough), while
the table was looking strictly for "unconfigured" flags.

The `default == recommended` pattern crops up in a couple of situations:

- Security-related fixes that we want to force on people, but want to
  give them a flag to back out of the changes if they really need to.
- Flags that changed their default value in the most recent major
  version.
- Flags that we've introduced at some point in the past, but have gone
  back on.

In this PR, make both bits of code use the same logic so discrepancies
like these can't happen anymore. Also add a header to the table so
it's clear what you're currently looking at.

Also in this PR: remove a dead `flags.ts` code, that had been fully
refactored to other files but had accidentally been left in.
@rix0rrr rix0rrr requested a review from a team November 28, 2025 14:38
@github-actions github-actions bot added the p2 label Nov 28, 2025
@aws-cdk-automation aws-cdk-automation requested a review from a team November 28, 2025 14:39
@codecov-commenter
Copy link

codecov-commenter commented Dec 1, 2025

Codecov Report

❌ Patch coverage is 96.92308% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.95%. Comparing base (33464fc) to head (9380450).

Files with missing lines Patch % Lines
packages/aws-cdk/lib/cli/cdk-toolkit.ts 33.33% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #967      +/-   ##
==========================================
+ Coverage   84.37%   85.95%   +1.57%     
==========================================
  Files          72       71       -1     
  Lines       10467    10001     -466     
  Branches     1347     1269      -78     
==========================================
- Hits         8832     8596     -236     
+ Misses       1594     1385     -209     
+ Partials       41       20      -21     
Flag Coverage Δ
suite.unit 85.95% <96.92%> (+1.57%) ⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@rix0rrr rix0rrr added this pull request to the merge queue Dec 1, 2025
Merged via the queue into main with commit 6693243 Dec 1, 2025
31 checks passed
@rix0rrr rix0rrr deleted the huijbers/flags-inconsistent branch December 1, 2025 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants