Adding a partitionKey to a Timestream table (or, create a resource that doesn't exist)

Question

tl;dr how can I add a partition key to a table in the CDK without destroying the entire stack?

---

I have a Timestream table which I created via the CDK, before AWS introduced support for customer defined partition keys.

new timestream.CfnTable(this, "MyTable", {
  databaseName: "my_database",
  tableName: "my_table",
})

I would like to add a partition key to this table. I know that it cannot be added to an existing table, and that I have to delete the table and recreate it with the partition key. In my case, that's okay. The data in this table isn't important.

The CDK will not do this for you if you add the partition key settings (which is sensible).

new timestream.CfnTable(this, "MyTable", {
  databaseName: "my_database",
  tableName: "my_table",
  schema: {
    compositePartitionKey: [
      { enforcementInRecord: "REQUIRED", name: partitionKeyName, type: "DIMENSION" },
    ],
  },
})

So I went into the AWS console and deleted the table manually. Now after running cdk deploy, I get this error:

❌ MyStack failed: Error: The stack named MyStack failed to deploy: UPDATE_ROLLBACK_COMPLETE: Resource handler returned message: "The table my_table does not exist. (Service: AmazonTimestreamWrite; Status Code: 404; Error Code: ResourceNotFoundException; Request ID: asdf123; Proxy: null)"

I don't understand why this is an error. If it does not exist, it should create it.

Annoyingly, if I change the logicalId "MyTable" to something else, then I get this contradictory error:

❌ MyStack failed: Error: The stack named MyStack failed to deploy: my_database|my_table already exists in stack

Another curiosity: I ran drift detection on this stack in the console, and no changes were detected.

How can I get the CDK to create a resource which I deleted from the console?

Answer 1

If you're able to do a cdk destroy && cdk deploy, that's the easiest thing to do. But in my case, there are resources which I cannot destroy without causing chaos in other systems.

So:

1. Leave the logicalId the same and change the table name to something else, like "my_table_foobar"
2. cdk deploy
3. Change the table name back to "my_table"
4. cdk deploy again

This is kind of a pain in the butt to do if, like me, you are deploying to separate environments via a controlled pipeline. But at least it's a one-time thing.