aws-redshift: Granting privileges to new tables does not work due to physical resource ID not being SQL table name #29231
Labels
@aws-cdk/aws-redshift
Related to Amazon Redshift
bug
This issue is a bug.
effort/medium
Medium work item – several days of effort
p2
Describe the bug
I updated from 2.31 to 2.127 and am now getting an error when deploying a new table. My previously existing tables in the same stack seem to be deploying fine (with no changes), but the deployment is failing when granting privileges to the new table.
It appears that this fairly straightforward use case of granting privileges to a user on a table is fundamentally broken. I would guess this would affect a large number of applications using these components.
Expected Behavior
Deploying my stack succeeds, and user privileges are properly granted to the table.
Current Behavior
I get the following error when the stack is deploying the
UserTablePrivileges
resource.Reproduction Steps
Possible Solution
After digging through the code changes, it seems that this regression was introduced in #24308. This change updated the custom resource handler for Table, changing the physical resource ID from the simple table name to the above composite ID form. However, the Table construct assigns this physical resource ID to its
tableName
property. The privileges code uses thistableName
property to construct the SQL statement, resulting in the syntax error during deployment.So far, I am working around this by just not updating to the latest version. I don't see this issue on 2.114. I imagine that it should be possible to work around the issue by using
Table.fromTableAttributes
to create anITable
with the desiredtableName
rather than reusing the result ofnew Table(...)
like normal. Though I think this would only work if not using an auto-generated table name.Additional Information/Context
No response
CDK CLI Version
2.127.0 (build 6c90efc)
Framework Version
No response
Node.js Version
20.x
OS
Amazon Linux 2
Language
TypeScript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: