Amplify push got error "Message: Resource is not in the state stackUpdateComplete" #92

lehoai · 2022-03-07T08:26:20Z

Before opening, please confirm:

I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
I have searched for duplicate or closed issues.
I have read the guide for submitting bug reports.
I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?

npm

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

No response

Amplify CLI Version

Using the latest version at amplify CI/CD

What operating system are you using?

Mac

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

No manual changes made

Amplify Categories

Not applicable

Amplify Commands

push

Describe the bug

I am using CI/CD which links with my GitHub master branch. The last few days ago, it work properly. But now when I try to merge source to master branch, I got the error:
[WARNING]: ✖ An error occurred when pushing the resources to the cloud
[WARNING]: ✖ There was an error initializing your environment.
[INFO]: DeploymentError: ["Index: 1 State: {\"deploy\":\"waitingForDeployment\"} Message: Resource is not in the state stackUpdateComplete"] at /root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/iterative-deployment/deployment-manager.ts:159:40 at Interpreter.update (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/interpreter.js:267:9) at /root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/interpreter.js:112:15 at Scheduler.process (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/scheduler.js:69:7) at Scheduler.flushEvents (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/scheduler.js:60:12) at Scheduler.schedule (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/scheduler.js:49:10) at Interpreter.send (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/interpreter.js:106:23) at _a.id (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/xstate/lib/interpreter.js:1017:15) at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:95:5)

Then I try with amplify CLI, get the same error too.

Expected behavior

push success.

Reproduction steps

I add a @connection, a @key, and few @aws_subscribe, then push

GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line

Additional information

No response

The text was updated successfully, but these errors were encountered:

akshbhu · 2022-03-08T09:15:07Z

Hi @lehoai

Can you share you gql schema and categories you have added so that I can reproduce it on my end ?

Also can you share the debug logs present here : ~/.amplify/logs/amplify-cli-<issue-date>.log

Also may I know which amplify version you are using?

batical · 2022-03-11T12:42:26Z

Got the same issue. very problematic, not able to push anything(dev or production-.

My log are 20k line long.

2022-03-11T12:00:38.110Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (1 of 3)"}])
2022-03-11T12:00:38.110Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:00:38.111Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (1 of 3)"}])
2022-03-11T12:00:39.234Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (1 of 3)"}])
2022-03-11T12:04:41.051Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Waiting for DynamoDB indices to be ready"}])
2022-03-11T12:04:44.266Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:04:44.493Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (2 of 3)"}])
2022-03-11T12:04:44.493Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:04:44.494Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (2 of 3)"}])
2022-03-11T12:04:45.634Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (2 of 3)"}])
2022-03-11T12:08:47.462Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Waiting for DynamoDB indices to be ready"}])
2022-03-11T12:09:51.696Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:09:51.920Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (3 of 3)"}])
2022-03-11T12:09:51.921Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:09:51.924Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (3 of 3)"}])
2022-03-11T12:09:52.941Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Deploying (3 of 3)"}])
2022-03-11T12:21:58.236Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:21:58.239Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (1 of 3)"}])
2022-03-11T12:21:58.240Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (2 of 3)"}])
2022-03-11T12:21:58.241Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:21:58.242Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (2 of 3)"}])
2022-03-11T12:21:58.478Z|error : amplify-provider-awscloudformation.deployment-manager.startRolbackFn([{"index":2}])
Error: Cannot start step then the current step is in ROLLING_BACK status.
2022-03-11T12:21:59.401Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (2 of 3)"}])
2022-03-11T12:26:01.228Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (2 of 3)"}])
2022-03-11T12:26:04.433Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:26:04.648Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (3 of 3)"}])
2022-03-11T12:26:04.650Z|info : amplify-provider-awscloudformation.aws-s3.uploadFile.s3.putObject([{"Key":"[***]ment-[***]json","Bucket":"[***]it-[***]ev-[***]161237-[***]ment"}])
2022-03-11T12:26:04.654Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (3 of 3)"}])
2022-03-11T12:26:05.732Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (3 of 3)"}])
2022-03-11T12:30:07.578Z|info : amplify-provider-awscloudformation.deployment-manager.deploy([{"spinner":"Rolling back (3 of 3)"}])

I try using the last version of amplify cli 7.6.23

here is some part of the log with the rollback starting

ecc7220 · 2022-03-11T13:18:22Z

I have the same issue, I pushed a few destructive changes to my GraphQL model and it failed because a token expired during the push.

2022-03-11T12:22:24.363Z|error : amplify-provider-awscloudformation.aws-s3.uploadFile.s3([{"Key":"[***]ment-[***]json","Bucket":"[***]ify-[***]pool-[***]ing-[***]316-[***]ment"}]) ExpiredToken: The provided token has expired. 2022-03-11T12:22:24.363Z|error : amplify-provider-awscloudformation.deployment-manager.startRolbackFn([{"index":2}]) ExpiredToken: The provided token has expired. 2022-03-11T12:22:38.638Z|error : amplify-provider-awscloudformation.deployment-manager.getTableStatus([{"tableName":"[***]er-[***]6sfqmjiikqe-[***]ing"}]) ExpiredTokenException: The security token included in the request is expired
I tried it again and got:

2022-03-11T12:24:18.467Z|info : amplify-provider-awscloudformation.deployment-manager.rollback([{"spinner":"Waiting for previous deployment to finish"}]) 2022-03-11T12:24:18.526Z|error : amplify-provider-awscloudformation.deployment-manager.DeploymentManager([{"stateValue":"failed"}]) DeploymentError: ["Index: 3 State: {\"preRollback\":\"previousDeploymentReadyCheck\"} Message: Resource is not in the state stackUpdateComplete"]
Then I pulled the lasted env and pushed and got again:

2022-03-11T12:35:34.798Z|info : amplify-provider-awscloudformation.deployment-manager.rollback([{"spinner":"Waiting for previous deployment to finish"}]) 2022-03-11T12:35:34.834Z|error : amplify-provider-awscloudformation.deployment-manager.DeploymentManager([{"stateValue":"failed"}]) DeploymentError: ["Index: 3 State: {\"preRollback\":\"previousDeploymentReadyCheck\"} Message: Resource is not in the state stackUpdateComplete"]
How can I solve this, I'm stuck, please provide steps to fix this, even if I need to remove some stuff, I need to get it working today!

My cli version is 7.6.23, using Cloud9 instance. Only some destructive updates to the model, since the last push. Recreation of tables not an issue right now.

ecc7220 · 2022-03-11T14:41:39Z

I did some research and there are tons of "Resource not in state stackUpdateComplete" issues that where never solved but simply closed. The guys have probably all recreated the whole environments.

Related issues containing "stackUpdateComplete" start at aws-amplify/amplify-cli#82 and goes all the way up to #95, with still 18 open issues and 149 closed issues including this one (#9925). Drifts in the stacks happen, you need to handle this properly IMHO. In my case it was the long time the update took, which caused a token to expire.

Amazon are you watching this very common ?

This is a no go.

This is clearly a high priority issue that should be solved once and for all times.
Recovery from push failures and stack drifts is very essential, this should simply just work all the time, like a file system.

EDIT:

I could find some more hints, if you change more than 2 indexes in a graphql model, the push fails, complaining about that too many parallel indexes where changed or deleted on a single table, I cant find the log about it, it was displayed on the terminal, but I lost it. The amplify log file in ~/amplify/logs/ is too long already, I can't find anything. After that, you will get the message "Resource is not in the state stackUpdateComplete" and you are stuck. The only way to get it back to work is the deletion and recreation of the environment. Steps I did (on your own risk):

Save all your data that is on the amplify controlled amplify storage, also archive the whole environment.
Backup all data in your database tables, you will need later to import that data back into new tables. In step 5, the env will be delete and all tables and storage s3 buckets will be deleted! Be careful, you are on your own risk.
Create a new env with: amplify env add your_new_env_name
You will be now in your new env, the code and backend config should still be there. You can see that with an: amplify status
Now delete your old env: amplify env remove broken_env_name (on your own risk)
Create a new env with the same name, this env will work: amplify env add broken_env_name
you should be in the new env now, check with: amplify status
Push your backend into the new env, this will take a while...
Now it's the time to reimport all your saved data from step 1 and 2.

The whole procedure takes a long time, is there a better or faster way to do it?

EDIT:

I'm very sure now, that this is caused by too many simultaneous dynamodb index updates on the same table, which hits on a dymanodb limit and that the expired token message was somehow only related to the first error. This also explains why some many people encounter this switching from V1 to V2 graphql models.

So we have two issues:

A failed push, for what ever reason needs to be recoverable.
GraphQL model updates trigger occasionally simultaneous index updates or deletions which abort the running amplify push, leaving you with an unrecoverable state.

lehoai · 2022-03-12T02:38:24Z

@akshbhu
Sorry, i was so busy.
I've changed my schema as above, and a few @subscription and @function.
@ecc7220
I cant create a new env because this is a production env.

batical · 2022-03-12T08:20:38Z

I was able to go though, pushing my changes step by step

pull env --restore
pushing multiple changes one by one until I found the error. Took me at least 4 hours ...

Issue cames from a @Index error, my bad, but at least an error message can be helpful.

lehoai · 2022-03-12T11:56:47Z

@batical
Can u give me more info?
The amplify error log is useless at all!

ecc7220 · 2022-03-12T14:13:56Z

@lehoai
I don't know how to recover from this error without recreating the env, sorry, but somebody with deeper knowledge needs to help out somehow. The only thing I could find out, is the cause of the error. Which comes from the index issue I mentioned above. So, don't change too much at once in the model, it could lead to a broken env.

ecc7220 · 2022-03-12T14:38:02Z

Issue #88 is also related, I had also tried everything, including the deletion of the "deployment-state.json" file in the corresponding amplify stage bucket. The issue described there is very similar. Only that in my case nothing helped.

@lehoai I would give it a try and delete the file and try pushing again, if you are lucky, you can get it back working.

lehoai · 2022-03-13T02:11:16Z

@ecc7220
Thanks. I will try.

ecc7220 · 2022-03-13T15:56:07Z

@lehoai if this is not working try also the solution for #88.
This includes modifying the deployment bucket as well.
It is a much better solution, as my solution recreating everything.
If I have next time a similar issue, I will try the suggested modification in #88.
Good luck!

lehoai · 2022-03-21T03:20:33Z

@ecc7220
Thanks, I will try.
I promise you this is the last time I work with Amplify. Terrible tool ever: Unstable, slow support, there is a lot of bugs!

josefaidt · 2022-03-21T17:56:42Z

Hey @lehoai 👋 apologies for the delay! Can you share the CloudFormation errors that are printed prior to receiving the Resource is not in the state stackUpdateComplete message? Typically when we see this error the CloudFormation errors provide additional insight

alharris-at · 2022-04-04T19:29:24Z

Hi @lehoai, In addition to the schema errors which Josef has mentioned above specifically, could you also provide a bit more data your environment? There are 2 things which we'd like to understand in a bit more details, auth token expiration and it's impact on your deployment, and the contents of the deployment itself.

What auth mechanism are you using for your account? i.e. are you using user access/secret keys for a given user, or are you using something like STS to generate short-lived federated tokens?
The schema you're starting out with when you kick off a deployment (previous schema).
Schema you are attempting to deploy.

This will help us get understanding of the changes being applied during the deployment. We can set up a call if you'd like as well, rather than sharing the schema publicly on GH, you can reach out to amplify-cli@amazon.com

lehoai · 2022-04-06T06:04:05Z

@alharris-at al
Sorry for the late reply.
Finally, we have to create a new env and redeploy the whole project. Then it worked. The old env was deleted. So I think it's not a problem with schema (i don't create or update any index).

I link the amplify with github in aws console, so it automatically re-deploys every time the source code is merged. I don't use access/secret keys
2, 3. as i said, i don't create or update any index, just add a few subscriptions and columns. I can't show the detail of the schema.

I've checked the error log many times, then there is only one reason "Resource is not in the state stackUpdateComplete", no more. ( i know, this error sometimes shows up when other error occurs, but not in my case, only "Resource is not in the state stackUpdateComplete" is thrown).

alharris-at · 2022-04-12T18:13:01Z

I see, thank you for the update @lehoai, we're going to create a new bug related to force push behavior in the AWS Console, which sounds related to what you're seeing here. Is there anything else specific we can help you out with on this issue?

josefaidt · 2022-04-12T18:13:02Z

Hey @lehoai 👋 thank you for those details! To clarify, do you have the affected backend files and would you be willing to send us a zip archive to amplify-cli@amazon.com? If so, we would like to take a look and see if we are able to reproduce the issue using your backend definition as we have been unable to reproduce this ourselves.

lehoai · 2022-04-14T03:24:50Z

@josefaidt @alharris-at
Thank you for your response. Honestly, I really wanna share the detail of the schema, and backend files but there is an NDA contract so I cant.
I gave u everything I can share above, the error log, part of the schema...

I think u should give more detail in the error log then the developers can investigate the cause.

naingaungphyo · 2022-04-26T05:33:00Z

I run amplify push and also got the same "Resource is not in the state stackUpdateComplete" error after changing many indexes and the primary key of one of my models.
I tried with this amplify/cli/json setting of enableIterativeGsiUpdates as true and also used --force and --allow-destructive-graphql-schema-updates cli flags according to this troubleshooting guide, but none of them works.

By the way, I didn't do any manual modification. (eg. from console etc)

My workaround was removing the api and adding api again as below.

backup my schema file
amplify remove api
amplify push
amplify add api and use my backup schema
amplify push
used cli version is 8.0.2 and v2 transformer

josefaidt · 2022-04-26T18:42:44Z

Hey @lehoai no worries on sending the schema. We will continue to investigate this issue.

@naingaungphyo are you seeing any CloudFormation errors outputted to your terminal and would you mind sharing the logs at ~/.amplify/logs the day this occurred? And finally, approximately how many changes were applied prior to receiving this error?

Tshetrim · 2023-04-07T01:58:50Z

@AnilMaktala Hello, so I went to S3 and deleted the deployment-state.json like others had it.

After doing so, the push did go through this time - I was not immediately stopped by the index issue. Unfortunately, after it tried to deploy it for a bit, just like the first time, the same error eventually came up.

I tried it twice for good measure.

KenObie · 2023-05-03T03:22:59Z

So...the solution is to stop using Amplify? Cheers

judygab · 2023-05-17T21:02:21Z

Hey @hackmajoris 👋, We are able to reproduce the issue with the provided steps and below schema. Steps to reproduce:

Here is the initial schema:
type ShorterLink @model {
  id: ID! @primaryKey(sortKeyFields: ["createdAt"])
  name: String!
  createdAt: String!
  shorterUrl: String
  originalUrl: String
  clicks: Int
  lastOpen: String
  description: String
  info: String
  logs: [Log] @hasMany
}


  type Log @model {
    id: ID! @primaryKey(sortKeyFields: ["createdAt"])
    createdAt: String!
    title: String!
    link: ShorterLink @belongsTo
  }
run amplify push -y After push, update Log model(remove sotKeyFields)
  type Log @model  {
    id: ID! @primaryKey
    createdAt: String!
    title: String!
    link: ShorterLink @belongsTo
  }
run amplify push --allow-destructive-graphql-schema-updates

So what is the right way of updating primary keys on a table? I am also encountering the same error when trying to do so

judygab · 2023-05-18T15:02:45Z

For anyone still wondering, what worked for me was just deploying without the table that you are to change primaryKey of and than adding the updated table and re-deployed. Figured since the table will be deleted regardless because of the change of the index, I would delete it myself because just updating the primaryKey didn't work for me.

Tshetrim · 2023-05-18T16:57:24Z

@judygab Hi Judy, thanks for the heads up. I've tried deleting the table thorough Dynamo before then deploying but I still got the same error.

Just to clarify, if you can, did you remove the table from your schema, delete the table through Dynamo, and then recompiled and deployed?

And then did that successfully deploy, and then you were you able to add in the table back to your schema and deploy successfully?

This was the sort of loop around I was hoping to find, so awesome if this works!

KenObie · 2023-05-20T08:23:53Z

For those who are still stuck. The root cause is a stuck deployment.json file that stores the deployment status. Ignore this horrible design choice and follow these steps.

Rollback deployment using the cli
Delete deployment.json in the root of the amplify s3 directory
Redeploy
Delete primary index and redeploy (1 table at a time).

judygab · 2023-05-22T16:45:55Z

@judygab Hi Judy, thanks for the heads up. I've tried deleting the table thorough Dynamo before then deploying but I still got the same error.

Just to clarify, if you can, did you remove the table from your schema, delete the table through Dynamo, and then recompiled and deployed?

And then did that successfully deploy, and then you were you able to add in the table back to your schema and deploy successfully?

This was the sort of loop around I was hoping to find, so awesome if this works!

Yes, so my steps were:

Remove the table from schema
Re-deploy(deployment was successful)
Add the table back with updated primary keys
Delete deployment.json from s3 bucket(I tried re-deploying but it got stuck with no errors, so wasn't able to stop it or try again because of stored deployment state)
Re-deploy

malmgrens4 · 2023-06-03T22:09:43Z

Ran into this as well. Deleting the deployment-status.json in s3 didn't work for me.
Ended up making a backup of my changes and pulling back down from the server with amplify pull to overwrite my local changes.
Then redeploying changes incrementally.
Really need amplify to have more detailed errors and better tolerance for multiple changes. They're bound to happen in early stages of a project.

omegabyte · 2023-06-10T17:31:48Z

What's the point --force if doesn't force?

hackmajoris · 2023-06-21T19:07:57Z

C'mon guys. Please prioritise this critical issue.

mgrabka · 2023-06-23T19:23:04Z

Ran into this as well. Deleting the deployment-status.json in s3 didn't work for me.
Ended up making a backup of my changes and pulling back down from the server with amplify pull to overwrite my local changes.
Then redeploying changes incrementally.
Really need amplify to have more detailed errors and better tolerance for multiple changes. They're bound to happen in early stages of a project.

Ran into this as well, and it's funny because even pulling and trying to push afterwards doesn't work for me.

nxia416 · 2023-06-24T02:51:55Z

Having the same problem.

malmgrens4 · 2023-06-24T03:27:01Z

One issue I ran into was trying to change which field the primary key was. Couldn't push after that.

chrisl777 · 2023-07-06T04:07:26Z

I ran into the same issue.

hackmajoris · 2023-07-06T06:03:54Z

I ran into the same issue.

If loosing the existing data is not a problem, you can delete the existing schema/table and then re-create it again with the required keyes.

evan1108 · 2023-07-12T14:00:53Z

I had the same problem. Removing the tables and re-adding one by one with the updated primary key as described above worked for me.

chrisl777 · 2023-07-12T16:30:52Z

In my case, I had the above error message with Storage, not the API.

What helped in my case was to run amplify update storage and run through all my settings.

At first, when changing settings, such as updating permissions, or adding a trigger, I was getting an error: Resolution error: statement.freeze is not a function aws amplify.

In my case, I think what was causing the issue was that I had a Lambda trigger for S3 that was not set up properly, I removed the link between S3 and the Lambda tigger and re-linked it. I also have an Admin group for Auth, and I needed to add permissions for Storage for that group as well. I also had an override.ts for my Storage where I had a policy:

   resources.s3GuestReadPolicy.policyDocument.statements.push({
     Effect: "Allow",
     Action: "s3:GetObject",
     Resource: `${resources.s3Bucket.attrArn}/public/*` 
   })

I think this policy may have been conflicting with the cli-inputs, so I commented out this policy.

After making these changes, I stopped getting errors when running amplify update storage and then my backend build succeeded.

Just putting it out there since I didn't see anyone mention Storage as throwing the error message in the original post above.

donkee1982 · 2023-09-03T21:34:44Z

I'm not sure if this will be helpful or if it might be a special case, but I'll describe the situation where I resolved the same error.
In conclusion, I checked and modified the contents of team-provider-info.json, and after doing so, the error was resolved, and the deployment succeeded.
In more detail, in my case, I was sharing a single backend between two applications, and there was a discrepancy in the environment variables of the functions section in team-provider-info.json. Once I corrected this, the error was resolved.
It seems that even after running the amplify pull command, the team-provider-info.json was not updated, leading to this situation.
This aspect was not shown in the logs of amplify console. I noticed this purely by chance.
I hope this proves useful to someone

hackmajoris · 2023-09-04T07:01:10Z

I'm not sure if this will be helpful or if it might be a special case, but I'll describe the situation where I resolved the same error. In conclusion, I checked and modified the contents of team-provider-info.json, and after doing so, the error was resolved, and the deployment succeeded. In more detail, in my case, I was sharing a single backend between two applications, and there was a discrepancy in the environment variables of the functions section in team-provider-info.json. Once I corrected this, the error was resolved. It seems that even after running the amplify pull command, the team-provider-info.json was not updated, leading to this situation. This aspect was not shown in the logs of amplify console. I noticed this purely by chance. I hope this proves useful to someone

Could you check your solution on these reproductio steps?
#92 (comment)

nikolaigeorgie · 2023-09-05T23:06:21Z

Not sure if anyone saw this but stack overflow top answer laid out best options. For me any change to schema.graphql would fail with the same error here. I had to

delete delete deployment-state.json in the s3 bucket for the deployment.
amplify push --force (failed for same reason)
step 1 again
amplify push --force

And the second time worked 🍭 . So perhaps deleting it 2-3 times.. is the trick.. 👀 lol

drewjhart · 2024-01-11T17:18:42Z

Has there been any movement on this? I am getting this whenever I want to add an @index to an existing table. Currently, I am recreating the env as a workaround, but that is less than ideal because anything in the DynamoDB tables need to be deleted.

KarthikPoonjar · 2024-04-17T20:55:34Z

What worked for me is the following:

First remove all the fields having @hasmany and @belongsTo , push
Add/remove primaryKey field and push

djom202 · 2024-05-03T23:20:30Z

Today i had the same issue, looking for a soluction or workarround, I found that one of thing that produce this issues is a conflict change in the infra code, so I think that the env in the cloud was working fine, I just create a backup from Amplify folder in order to don't forget which changes were made so I delete the amplify folder and I just pull the entire env. It's just a band-aid; it's only a temporary fix until a permanent solution is found.

I hope it serves you well

akshbhu added pending-triage graphql-transformer-v1 pending-close-response-required labels Mar 8, 2022

josefaidt removed the pending-close-response-required label Mar 21, 2022

josefaidt added the p1 label Mar 31, 2022

alharris-at added pending-response and removed pending-triage labels Apr 12, 2022

josefaidt added the pending-triage label Apr 12, 2022

josefaidt added ops-errors and removed pending-response labels Apr 15, 2022

AnilMaktala mentioned this issue May 18, 2023

Point amplify to a working state of initial-stack #1425

Open

AnilMaktala mentioned this issue Jun 6, 2023

Deployment error when changing DynamoDB model and force --allow-destructive-graphql-schema-updates #1536

Closed

phani-srikar mentioned this issue Jun 17, 2023

How to fix "["Index: 3 State: {\"deploy\":\"waitingForDeployment\"} Message: Resource is not in the state stackUpdateComplete"]" error #1478

Closed

alharris-at added theme:brittle-cloudformation theme:dynamodb-iterative-deployments and removed theme:brittle-cloudformation labels Aug 18, 2023

dpilch mentioned this issue Feb 29, 2024

Amplify push hangs indefinitely after failed cloudformation updates #2305

Open

2 tasks

Amplify push got error "Message: Resource is not in the state stackUpdateComplete" #92

Amplify push got error "Message: Resource is not in the state stackUpdateComplete" #92

Comments

lehoai commented Mar 7, 2022

Before opening, please confirm:

How did you install the Amplify CLI?

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

Amplify CLI Version

What operating system are you using?

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

Amplify Categories

Amplify Commands

Describe the bug

Expected behavior

Reproduction steps

GraphQL schema(s)

Log output

Additional information

akshbhu commented Mar 8, 2022 • edited Loading

batical commented Mar 11, 2022 • edited Loading

ecc7220 commented Mar 11, 2022

ecc7220 commented Mar 11, 2022 • edited Loading

EDIT:

EDIT:

lehoai commented Mar 12, 2022

batical commented Mar 12, 2022

lehoai commented Mar 12, 2022

ecc7220 commented Mar 12, 2022

ecc7220 commented Mar 12, 2022

lehoai commented Mar 13, 2022

ecc7220 commented Mar 13, 2022

lehoai commented Mar 21, 2022

josefaidt commented Mar 21, 2022

alharris-at commented Apr 4, 2022 • edited Loading

lehoai commented Apr 6, 2022

alharris-at commented Apr 12, 2022

josefaidt commented Apr 12, 2022

lehoai commented Apr 14, 2022

naingaungphyo commented Apr 26, 2022 • edited Loading

josefaidt commented Apr 26, 2022

Tshetrim commented Apr 7, 2023

KenObie commented May 3, 2023

judygab commented May 17, 2023

judygab commented May 18, 2023

Tshetrim commented May 18, 2023

KenObie commented May 20, 2023

judygab commented May 22, 2023

malmgrens4 commented Jun 3, 2023

omegabyte commented Jun 10, 2023

hackmajoris commented Jun 21, 2023

mgrabka commented Jun 23, 2023

nxia416 commented Jun 24, 2023

malmgrens4 commented Jun 24, 2023

chrisl777 commented Jul 6, 2023

hackmajoris commented Jul 6, 2023 • edited Loading

evan1108 commented Jul 12, 2023

chrisl777 commented Jul 12, 2023

donkee1982 commented Sep 3, 2023

hackmajoris commented Sep 4, 2023 • edited Loading

nikolaigeorgie commented Sep 5, 2023

drewjhart commented Jan 11, 2024

KarthikPoonjar commented Apr 17, 2024

djom202 commented May 3, 2024

akshbhu commented Mar 8, 2022 •

edited

Loading

batical commented Mar 11, 2022 •

edited

Loading

ecc7220 commented Mar 11, 2022 •

edited

Loading

alharris-at commented Apr 4, 2022 •

edited

Loading

naingaungphyo commented Apr 26, 2022 •

edited

Loading

hackmajoris commented Jul 6, 2023 •

edited

Loading

hackmajoris commented Sep 4, 2023 •

edited

Loading