feat(cli): cdk rollback (#31684)

This is a re-draft of #31407.  All description and motivation of the previous PR still apply.

The previous PR caused a regression because some `CREATE_IN_PROGRESS` events for CloudFormation do not have a `PhysicalResourceId`.

Fix that issue in this PR. Update the existing unit test that was supposed to catch this issue previously, it did not set a `ResourceStatus` which caused the event to be skipped for the wrong reason.

----

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

Author: rix0rrr

Diff for: packages/@aws-cdk-testing/cli-integ/README.md

@@ -37,7 +37,7 @@ Test suites are written as a collection of Jest tests, and they are run using Je
 
 ### Setup
 
-Building the @aws-cdk-testing package is not very different from building the rest of the CDK. However, If you are having issues with the tests, you can ensure your enviornment is built properly by following the steps below:
+Building the @aws-cdk-testing package is not very different from building the rest of the CDK. However, If you are having issues with the tests, you can ensure your environment is built properly by following the steps below:
 
 ```shell
 yarn install # Install dependencies

Diff for: packages/@aws-cdk-testing/cli-integ/lib/with-cdk-app.ts

@@ -24,7 +24,8 @@ export const EXTENDED_TEST_TIMEOUT_S = 30 * 60;
  * For backwards compatibility with existing tests (so we don't have to change
  * too much) the inner block is expected to take a `TestFixture` object.
  */
-export function withCdkApp(
+export function withSpecificCdkApp(
+  appName: string,
   block: (context: TestFixture) => Promise<void>,
 ): (context: TestContext & AwsContext & DisableBootstrapContext) => Promise<void> {
   return async (context: TestContext & AwsContext & DisableBootstrapContext) => {
@@ -36,7 +37,7 @@ export function withCdkApp(
     context.output.write(` Test directory: ${integTestDir}\n`);
     context.output.write(` Region:         ${context.aws.region}\n`);
 
-    await cloneDirectory(path.join(RESOURCES_DIR, 'cdk-apps', 'app'), integTestDir, context.output);
+    await cloneDirectory(path.join(RESOURCES_DIR, 'cdk-apps', appName), integTestDir, context.output);
     const fixture = new TestFixture(
       integTestDir,
       stackNamePrefix,
@@ -87,6 +88,16 @@ export function withCdkApp(
   };
 }
 
+/**
+ * Like `withSpecificCdkApp`, but uses the default integration testing app with a million stacks in it
+ */
+export function withCdkApp(
+  block: (context: TestFixture) => Promise<void>,
+): (context: TestContext & AwsContext & DisableBootstrapContext) => Promise<void> {
+  // 'app' is the name of the default integration app in the `cdk-apps` directory
+  return withSpecificCdkApp('app', block);
+}
+
 export function withCdkMigrateApp<A extends TestContext>(language: string, block: (context: TestFixture) => Promise<void>) {
   return async (context: A) => {
     const stackName = `cdk-migrate-${language}-integ-${context.randomString}`;
@@ -188,6 +199,10 @@ export function withDefaultFixture(block: (context: TestFixture) => Promise<void
   return withAws(withTimeout(DEFAULT_TEST_TIMEOUT_S, withCdkApp(block)));
 }
 
+export function withSpecificFixture(appName: string, block: (context: TestFixture) => Promise<void>) {
+  return withAws(withTimeout(DEFAULT_TEST_TIMEOUT_S, withSpecificCdkApp(appName, block)));
+}
+
 export function withExtendedTimeoutFixture(block: (context: TestFixture) => Promise<void>) {
   return withAws(withTimeout(EXTENDED_TEST_TIMEOUT_S, withCdkApp(block)));
 }

Diff for: packages/@aws-cdk-testing/cli-integ/resources/cdk-apps/rollback-test-app/app.js

@@ -0,0 +1,100 @@
+const cdk = require('aws-cdk-lib');
+const lambda = require('aws-cdk-lib/aws-lambda');
+const cr = require('aws-cdk-lib/custom-resources');
+
+/**
+ * This stack will be deployed in multiple phases, to achieve a very specific effect
+ *
+ * It contains resources r1 and r2, where r1 gets deployed first.
+ *
+ * - PHASE = 1: both resources deploy regularly.
+ * - PHASE = 2a: r1 gets updated, r2 will fail to update
+ * - PHASE = 2b: r1 gets updated, r2 will fail to update, and r1 will fail its rollback.
+ *
+ * To exercise this app:
+ *
+ * ```
+ * env PHASE=1 npx cdk deploy
+ * env PHASE=2b npx cdk deploy --no-rollback
+ * # This will leave the stack in UPDATE_FAILED
+ *
+ * env PHASE=2b npx cdk rollback
+ * # This will start a rollback that will fail because r1 fails its rollabck
+ *
+ * env PHASE=2b npx cdk rollback --force
+ * # This will retry the rollabck and skip r1
+ * ```
+ */
+class RollbacktestStack extends cdk.Stack {
+  constructor(scope, id, props) {
+    super(scope, id, props);
+
+    let r1props = {};
+    let r2props = {};
+
+    const phase = process.env.PHASE;
+    switch (phase) {
+      case '1':
+        // Normal deployment
+        break;
+      case '2a':
+        // r1 updates normally, r2 fails updating
+        r2props.FailUpdate = true;
+        break;
+      case '2b':
+        // r1 updates normally, r2 fails updating, r1 fails rollback
+        r1props.FailRollback = true;
+        r2props.FailUpdate = true;
+        break;
+    }
+
+    const fn = new lambda.Function(this, 'Fun', {
+      runtime: lambda.Runtime.NODEJS_LATEST,
+      code: lambda.Code.fromInline(`exports.handler = async function(event, ctx) {
+        const key = \`Fail\${event.RequestType}\`;
+        if (event.ResourceProperties[key]) {
+          throw new Error(\`\${event.RequestType} fails!\`);
+        }
+        if (event.OldResourceProperties?.FailRollback) {
+          throw new Error('Failing rollback!');
+        }
+        return {};
+      }`),
+      handler: 'index.handler',
+      timeout: cdk.Duration.minutes(1),
+    });
+    const provider = new cr.Provider(this, "MyProvider", {
+      onEventHandler: fn,
+    });
+
+    const r1 = new cdk.CustomResource(this, 'r1', {
+      serviceToken: provider.serviceToken,
+      properties: r1props,
+    });
+    const r2 = new cdk.CustomResource(this, 'r2', {
+      serviceToken: provider.serviceToken,
+      properties: r2props,
+    });
+    r2.node.addDependency(r1);
+  }
+}
+
+const app = new cdk.App({
+  context: {
+    '@aws-cdk/core:assetHashSalt': process.env.CODEBUILD_BUILD_ID, // Force all assets to be unique, but consistent in one build
+  },
+});
+
+const defaultEnv = {
+  account: process.env.CDK_DEFAULT_ACCOUNT,
+  region: process.env.CDK_DEFAULT_REGION
+};
+
+const stackPrefix = process.env.STACK_NAME_PREFIX;
+if (!stackPrefix) {
+  throw new Error(`the STACK_NAME_PREFIX environment variable is required`);
+}
+
+// Sometimes we don't want to synthesize all stacks because it will impact the results
+new RollbacktestStack(app, `${stackPrefix}-test-rollback`, { env: defaultEnv });
+app.synth();

Diff for: packages/@aws-cdk-testing/cli-integ/resources/cdk-apps/rollback-test-app/cdk.json

@@ -0,0 +1,7 @@
+{
+  "app": "node app.js",
+  "versionReporting": false,
+  "context": {
+    "aws-cdk:enableDiffNoFail": "true"
+  }
+}

Diff for: packages/@aws-cdk-testing/cli-integ/tests/cli-integ-tests/cli.integtest.ts

@@ -32,6 +32,7 @@ import {
   withCDKMigrateFixture,
   withExtendedTimeoutFixture,
   randomString,
+  withSpecificFixture,
   withoutBootstrap,
 } from '../../lib';
 
@@ -2325,6 +2326,84 @@ integTest(
   }),
 );
 
+integTest(
+  'test cdk rollback',
+  withSpecificFixture('rollback-test-app', async (fixture) => {
+    let phase = '1';
+
+    // Should succeed
+    await fixture.cdkDeploy('test-rollback', {
+      options: ['--no-rollback'],
+      modEnv: { PHASE: phase },
+      verbose: false,
+    });
+    try {
+      phase = '2a';
+
+      // Should fail
+      const deployOutput = await fixture.cdkDeploy('test-rollback', {
+        options: ['--no-rollback'],
+        modEnv: { PHASE: phase },
+        verbose: false,
+        allowErrExit: true,
+      });
+      expect(deployOutput).toContain('UPDATE_FAILED');
+
+      // Rollback
+      await fixture.cdk(['rollback'], {
+        modEnv: { PHASE: phase },
+        verbose: false,
+      });
+    } finally {
+      await fixture.cdkDestroy('test-rollback');
+    }
+  }),
+);
+
+integTest(
+  'test cdk rollback --force',
+  withSpecificFixture('rollback-test-app', async (fixture) => {
+    let phase = '1';
+
+    // Should succeed
+    await fixture.cdkDeploy('test-rollback', {
+      options: ['--no-rollback'],
+      modEnv: { PHASE: phase },
+      verbose: false,
+    });
+    try {
+      phase = '2b'; // Fail update and also fail rollback
+
+      // Should fail
+      const deployOutput = await fixture.cdkDeploy('test-rollback', {
+        options: ['--no-rollback'],
+        modEnv: { PHASE: phase },
+        verbose: false,
+        allowErrExit: true,
+      });
+
+      expect(deployOutput).toContain('UPDATE_FAILED');
+
+      // Should still fail
+      const rollbackOutput = await fixture.cdk(['rollback'], {
+        modEnv: { PHASE: phase },
+        verbose: false,
+        allowErrExit: true,
+      });
+
+      expect(rollbackOutput).toContain('Failing rollback');
+
+      // Rollback and force cleanup
+      await fixture.cdk(['rollback', '--force'], {
+        modEnv: { PHASE: phase },
+        verbose: false,
+      });
+    } finally {
+      await fixture.cdkDestroy('test-rollback');
+    }
+  }),
+);
+
 integTest('cdk notices are displayed correctly', withDefaultFixture(async (fixture) => {
 
   const cache = {

Diff for: packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md

@@ -1143,7 +1143,7 @@ shipped as part of the runtime environment.
 
 *When enabled, will always use the arn for identifiers for CfnSourceApiAssociation in the GraphqlApi construct rather than id.* (fix)
 
-When this feature flag is enabled, we use the IGraphqlApi ARN rather than ID when creating or updating CfnSourceApiAssociation in 
+When this feature flag is enabled, we use the IGraphqlApi ARN rather than ID when creating or updating CfnSourceApiAssociation in
 the GraphqlApi construct. Using the ARN allows the association to support an association with a source api or merged api in another account.
 Note that for existing source api associations created with this flag disabled, enabling the flag will lead to a resource replacement.
 
@@ -1200,7 +1200,7 @@ database cluster from a snapshot.
 
 *When enabled, the CodeCommit source action is using the default branch name 'main'.* (fix)
 
-When setting up a CodeCommit source action for the source stage of a pipeline, please note that the 
+When setting up a CodeCommit source action for the source stage of a pipeline, please note that the
 default branch is 'master'.
 However, with the activation of this feature flag, the default branch is updated to 'main'.
 
@@ -1378,7 +1378,7 @@ Other notifications that are not managed by this stack will be kept.
 Currently, 'inputPath' and 'outputPath' from the TaskStateBase Props is being used under BedrockInvokeModelProps to define S3URI under 'input' and 'output' fields
 of State Machine Task definition.
 
-When this feature flag is enabled, specify newly introduced props 's3InputUri' and 
+When this feature flag is enabled, specify newly introduced props 's3InputUri' and
 's3OutputUri' to populate S3 uri under input and output fields in state machine task definition for Bedrock invoke model.
 
 
@@ -1413,7 +1413,7 @@ When this feature flag is enabled, we will only grant the necessary permissions
 *When enabled, initOptions.timeout and resourceSignalTimeout values will be summed together.* (fix)
 
 Currently is both initOptions.timeout and resourceSignalTimeout are both specified in the options for creating an EC2 Instance,
-only the value from 'resourceSignalTimeout' will be used. 
+only the value from 'resourceSignalTimeout' will be used.
 
 When this feature flag is enabled, if both initOptions.timeout and resourceSignalTimeout are specified, the values will to be summed together.
 
@@ -1428,11 +1428,11 @@ When this feature flag is enabled, if both initOptions.timeout and resourceSigna
 
 *When enabled, a Lambda authorizer Permission created when using GraphqlApi will be properly scoped with a SourceArn.* (fix)
 
-Currently, when using a Lambda authorizer with an AppSync GraphQL API, the AWS CDK automatically generates the necessary AWS::Lambda::Permission 
-to allow the AppSync API to invoke the Lambda authorizer. This permission is overly permissive because it lacks a SourceArn, meaning 
+Currently, when using a Lambda authorizer with an AppSync GraphQL API, the AWS CDK automatically generates the necessary AWS::Lambda::Permission
+to allow the AppSync API to invoke the Lambda authorizer. This permission is overly permissive because it lacks a SourceArn, meaning
 it allows invocations from any source.
 
-When this feature flag is enabled, the AWS::Lambda::Permission will be properly scoped with the SourceArn corresponding to the 
+When this feature flag is enabled, the AWS::Lambda::Permission will be properly scoped with the SourceArn corresponding to the
 specific AppSync GraphQL API.
 
 
@@ -1446,7 +1446,7 @@ specific AppSync GraphQL API.
 
 *When enabled, both `@aws-sdk` and `@smithy` packages will be excluded from the Lambda Node.js 18.x runtime to prevent version mismatches in bundled applications.* (fix)
 
-Currently, when bundling Lambda functions with the non-latest runtime that supports AWS SDK JavaScript (v3), only the '@aws-sdk/*' packages are excluded by default. 
+Currently, when bundling Lambda functions with the non-latest runtime that supports AWS SDK JavaScript (v3), only the '@aws-sdk/*' packages are excluded by default.
 However, this can cause version mismatches between the '@aws-sdk/*' and '@smithy/*' packages, as they are tightly coupled dependencies in AWS SDK v3.
 
 When this feature flag is enabled, both '@aws-sdk/*' and '@smithy/*' packages will be excluded during the bundling process. This ensures that no mismatches