aws-amplify / amplify-cli

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development.
Apache License 2.0
2.8k stars 819 forks source link

Dependency checks - DynamoDB table was deleted although another backend environment was using the same #13634

Open shashankmc opened 4 months ago

shashankmc commented 4 months ago

How did you install the Amplify CLI?

npm

If applicable, what version of Node.js are you using?

v20.11.1

Amplify CLI Version

12.10.1

What operating system are you using?

Windows

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No manual changes were made, just amplify backend environment was deleted.

Describe the bug

We have multiple amplify backend environments running for testing and dev use cases but rely on the same DynamoDB table for data (making things easier for us manage). One of the backend environments was deleted as it was redundant on the assumption that the Dynamo DB table, cognito service are going to be untouched as there are other backend environments using them. But that wasn't the case, it was deleted anyway leading to our application just crashing.

The reason I state this as a bug is because when we try to unlink auth services, amplify checks dependencies and disallows us to do that, which is good. The thing I do not understand is - why isn't there a similar check when services are automatically deleted but are being used by other backend environments? I'm not sure if I'm missing something here or following bad practice but I would assume that there would be dependency checks when amplify is automatically deleting services when there are other environments using them.

Expected behavior

Expectation is that if multiple backend environments are using services like DynamoDB (the same tables within the service) and Cognito (the same User pools and Identity pools), when a user deletes a backend environment in the front end, these services and their objects would remain intact rather than just get deleted. Expectation is that there is a dependency check.

Reproduction steps

  1. Create multiple backend environments.
  2. Update environment variables to point towards the same DynamoDB table, same Cognito user pools and identity pools.
  3. Delete one the backend env and even if the other backend envs are dependent on services like DynamoDB and Cognito (the same tables and identity pools respectively), those objects within these dependent services get deleted.

Project Identifier

No response

Log output

``` # Put your logs below this line ```

Additional information

No response

Before submitting, please confirm:

josefaidt commented 4 months ago

Hey @shashankmc :wave: thanks for raising this! As we begin to look into this in more depth I have a few follow-up questions to better understand the context

shashankmc commented 4 months ago

@josefaidt Thanks for getting back.

  1. It is imported through amplify import storage.
  2. Apologies, should have made that clearer. The lambda function associated, and their environment variables is what I meant.
  3. Due to the mess-up, still trying to restore everything and don't have that file as amplify pull with app id and env fails due to cognito deleted service dependency conflict.
  4. Project id: ddfe201e055129aa8091b20849754366
josefaidt commented 4 months ago

Hey @shashankmc thanks for clarifying! Is the imported table a table created by the API in another environment?

Are there multiple environments using imported auth and storage from a "host" environment?

shashankmc commented 4 months ago

Yes. It was initially created for an environment using the API and then imported to other environments.

josefaidt commented 4 months ago

Was the host environment the one that was deleted?

shashankmc commented 4 months ago

Yes but after having lambda functions (of the new backend env) environment variables point to the same DB table as the host.

josefaidt commented 3 months ago

Hey @shashankmc the CLI will currently check and validate resource dependencies within the same environment, but does not check across stacks for dependent, imported/referenced resources. I'll mark this as a feature request to improve the checks for imported resources.