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

[shashankmc]

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:

• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• [X] I have removed any sensitive information from my code snippets and submission.

[josefaidt]

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

• how is this shared DynamoDB table linked to other environments? is it imported with amplify import storage?
• from the reproduction steps, can you clarify which environment variables are updated? is this referring to values fed into the client library during Amplify.configure for manually configuring the frontend client?
• would you mind sharing your team-provider-info.json file?
• may you also share the project ID output from amplify diagnose --send-report?

[shashankmc]

@josefaidt Thanks for getting back.

1. It is imported through amplify import storage.
2. Apologies, should have made that clear_er_. 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]

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]

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

[josefaidt]

Was the host environment the one that was deleted?

[shashankmc]

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

[josefaidt]

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.