Open shashankmc opened 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
amplify import storage
?Amplify.configure
for manually configuring the frontend client?team-provider-info.json
file?amplify diagnose --send-report
?@josefaidt Thanks for getting back.
amplify import storage
.amplify pull
with app id and env fails due to cognito deleted service dependency conflict.ddfe201e055129aa8091b20849754366
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?
Yes. It was initially created for an environment using the API and then imported to other environments.
Was the host environment the one that was deleted?
Yes but after having lambda functions (of the new backend env) environment variables point to the same DB table as the host.
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.
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
Project Identifier
No response
Log output
Additional information
No response
Before submitting, please confirm: