Point amplify to a working state of initial-stack

[vgthoppae]

Amplify CLI Version

11.1.0

Question

Hello all, With recent changes, local amplify push fails with the classic error:

["Index: 0 State: {\"deploy\":\"waitingForDeployment\"} Message: Resource is not in the state stackUpdateComplete"]

Cloudformation stack Events say "Cannot perform more than one GSI creation or deletion in a single update".

Except that my model previously had defined multiple new indexes, but the current version defines no indexes. I've tried --iterative-rollback and --force options in vain. Also tried deleting deployment-state.json file from S3.

On closer inspection, I see that amplify/backend/api/${apiName}/build folder has a states folder with sub-folders for initial-stack, 01, 02 etc., Apparently these folders are built with a version of a stack for the affected table that is still attempting to create multiple indexes at the same time.

I believe that amplify pulls this state information from deployment-state.json file in the S3 deployment bucket which defines different steps, with the "previousMetaKey" key in the first step to a version of uniquely identified "amplify-appsync-files", something like.

{
  "status": "DEPLOYING",
  "previousMetaKey": "amplify-appsync-files/XXX24bcb992d84bfcb73ce23a914aXXX/states/initial-stack/deployment-meta.json"
}

Apparently the initial-stack from the above location defines multiple indexes for the affected table. I was able to trace back and find a past state (say YYY) that defines no indexes for the subject table. My question is if there is a way to tell amplify to consider that YYY state as the previousMetaKey.

I know I am describing a problem and asking for help on a particular way of fixing it. I'm open for other suggestions as well. I hate to create a new environment as there is quite a bit of data that the current environment is primed up with, and not surprisingly, there is a critical demo coming up.

[AnilMaktala]

Hey @vgthoppaen, Thank you for raising this. Have you made any modifications to the model, such as removing or adding indexes?

[vgthoppae]

Hi @AnilMaktala Thanks for the response. Yes, I did modify the affected model adding 3 or 4 indexes, tried to deploy it, failed and reverted the change. The problem is that it appears still amplify somehow us using the prior version to deploy.

[AnilMaktala]

Hey @vgthoppae, Thank you for the clarification. Would you mind executing the amplify push --allow-destructive-graphql-schema-updates command with your previous model version and informing me if it solves the problem?

Note: Please verify this command in Dev or lower before executing in the PROD.

[vgthoppae]

Hi @AnilMaktala tried that already, no luck unfortunately.

[AnilMaktala]

Hi @vgthoppae, can you please retry deleting the deployment-state.json file from S3 and send us the logs.

[vgthoppae]

amplify-cli-2023-04-28.log.zip

@AnilMaktala PFA. Thanks for your time.

[AnilMaktala]

Hi @vgthoppae, I have contacted the Engineering team to seek their help in resolving this issue.

[vgthoppae]

Hi @AnilMaktala thanks for staying on top of this. Yeah, it will be great to gain some insights on this.

[AnilMaktala]

Hi @vgthoppae, Sorry for the delay. Could you please attempt the following steps and notify us if you are able to push successfully.

1. Delete the deployment-state.json file and rollback all the new changes in schema file.
2. Run amplify push. if this step is successful, proceed to step 3.
3. Add one new change to schema and run amplify push. Repeat this step for the remaining schema changes.

[vgthoppae]

Hi @AnilMaktala Thanks for the response. If you read my original post, I have tried all these options already.

[AnilMaktala]

This seems to be a duplicate of #92.