Is cdk refactor working at all?

[EHadoux]

Hi everyone,

I'm trying to refactor a resource, just moving one table from one stack to another one and I have the feeling that the detection is way too rigid.

Here is the diff between the template on CloudFormation (source) and the synth'd stack (target)

{
+ "TrackingTable170A6688": {
- "TrackingStatefulTrackingTable4714DF64": {
    "Type": "AWS::DynamoDB::Table",
    "Properties": {
      "AttributeDefinitions": [
        {
          "AttributeName": "user_sub",
          "AttributeType": "S"
        },
        {
          "AttributeName": "client",
          "AttributeType": "S"
        }
      ],
      "BillingMode": "PAY_PER_REQUEST",
      "DeletionProtectionEnabled": false,
      "GlobalSecondaryIndexes": [
        {
          "IndexName": "byClient",
          "KeySchema": [
            {
              "AttributeName": "client",
              "KeyType": "HASH"
            }
          ],
          "Projection": {
            "ProjectionType": "ALL"
          }
        }
      ],
      "KeySchema": [
        {
          "AttributeName": "user_sub",
          "KeyType": "HASH"
        }
      ],
      "Tags": [
-        {
-          "Key": "feature",
-          "Value": "tracking"
-        },
-        {
-          "Key": "Name",
-          "Value": "tracking"
-        },
        {
          "Key": "product",
          "Value": "database"
        },
+     {
+         "Key": "service",
+         "Value": "users"
+      },
        {
          "Key": "stage",
          "Value": "dev"
        }
      ]
    },
    "UpdateReplacePolicy": "Delete",
    "DeletionPolicy": "Delete",
    "Metadata": {
+     "aws:cdk:path": "Dev/Users/TrackingTable/Resource",
-      "aws:cdk:path": "Dev/Stateful/TrackingStateful/TrackingTable/Resource",
      "cdk_nag": {
        "rules_to_suppress": [
          {
            "reason": "CDK managed",
            "id": "AwsSolutions-IAM4",
            "applies_to": [
              "Policy::arn:<AWS::Partition>:iam::aws:policy/CloudWatchAgentServerPolicy",
              "Policy::arn:<AWS::Partition>:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy",
              "Policy::arn:<AWS::Partition>:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs",
              "Policy::arn:<AWS::Partition>:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
              "Policy::arn:<AWS::Partition>:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole",
              "Policy::arn:<AWS::Partition>:iam::aws:policy/service-role/AWSAppSyncPushToCloudWatchLogs"
            ]
          },
          {
            "reason": "CDK managed",
            "id": "AwsSolutions-IAM5"
          }
        ]
      }
    }
  }
}

The command cdk --profile main-dev refactor "Dev/Stateful" "Dev/Users" --unstable=refactor --dry-run gives me the following output:

❌ Refactor failed: A refactor operation cannot add, remove or update resources. Only resource moves and renames are allowed.
The following resources are present only in the AWS environment:

• Dev/Stateful/TrackingStateful/TrackingTable/Resource

The following resources are present only in your CDK application:

• Dev/Users/TrackingTable/Resource

The following stacks were used in the comparison:

• Deployed: DevStateful48670B2D, DevUsers54D39DB1
• Local: DevStateful48670B2D, DevUsers54D39DB1

Hint: by default, only deployed stacks that have the same name as a local stack are included.
If you want to include additional deployed stacks for comparison, re-run the command with the option '--additional-stack-name=' for each stack.

There is something that I fundamentally don't understand here. I've also tried with --override-file to no avail.
If tags and metadata are taken into account for the matching algo, I have the feeling it should not, especially when tags can be applied at the stack level down the whole hierarchy, it feels counter productive.

Any idea of what I'm doing wrong?
Thanks everyone!

[pecirep]

did. you ever get this figured out? Having very similar issues..

[EHadoux]

No, I just abandoned because this is only the tip of the iceberg. There are so many other issues with the CDK that can play adversarially (e.g., lambda asset hash constantly changing even without any code change) that it feels like more hassle than benefits at this point.