When the destroy step to remove the CreateSchemaStack runs, it triggers the lambda to create the database tables. This results in duplicate entries into the database.
Workaround: Destroy the stack and then drop the tables, this way you won't end up with duplicates.
Steps to reproduce the issue
It's not always consistent.
Drop the tables in datagrip
Run CDK destroy on CreateSchemaStack
See that the tables have been recreated
Expected behavior (What should happen)
The destroy should either destroy the tables or leave them deleted
Actual behavior (What does happen)
The destroy runs the create tables lambda
Code Snippet:
No response
Additional notes, affected areas, and suggested fixes
Suggested fixes:
Add a check in the lambda for database non-existence
Make it so the lambda drops any existing tables as a first step
Make it so the lambda checks to see if the db entries exist before creating them
generally, making the lambda idempotent is probably the best way to fix this
Description of the issue
When the destroy step to remove the CreateSchemaStack runs, it triggers the lambda to create the database tables. This results in duplicate entries into the database.
Workaround: Destroy the stack and then drop the tables, this way you won't end up with duplicates.
Steps to reproduce the issue
It's not always consistent.
Expected behavior (What should happen)
The destroy should either destroy the tables or leave them deleted
Actual behavior (What does happen)
The destroy runs the create tables lambda
Code Snippet:
No response
Additional notes, affected areas, and suggested fixes
Suggested fixes:
More info in this slack thread