AWS Amplify：資源不在 state stackUpdateComplete 中

Question

我正在為我的項目設置 aws-amplify。 當我第一次配置它工作正常時，我在放大推送方面遇到了問題。 現在我更改了存儲庫，因為我必須從舊存儲庫中做子樹。 現在當我做放大推我得到

資源不在 state stackUpdateComplete

⠸ 更新雲端資源。 這可能需要幾分鍾...更新雲形成堆棧時出錯⠸ 更新雲中的資源。 這可能需要幾分鍾的時間...

關注資源失敗

✖ 將資源推送到雲端時出錯

Resource is not in the state stackUpdateComplete 推送操作期間發生錯誤：Resource is not in the state stackUpdateComplete

Answer 1

只是為了提供有關此錯誤的一些背景信息 - Resource is not in the state stackUpdateComplete實際上是什么意思？

基本上 Amplify 是在告訴您您的應用程序中的一個堆棧沒有正確部署，但它不知道為什么（這非常無益，但公平地說它正在部署許多潛在的復雜資源）。

這會使診斷和解決問題變得非常困難，所以我編制了這種心理清單，我 go 通過它來修復它。 每種技術都會在某些時候起作用，但我認為沒有任何技術會一直起作用。 此列表並非旨在幫助您診斷導致此問題的原因，它實際上只是為了讓您恢復正常運行而設計的。

快速選項（將解決大多數問題）

• 嘗試運行amplify push --iterative-rollback 。 它應該將您的環境回滾到上次成功部署，但它很少起作用。
• 嘗試運行amplify push --force 。 雖然違反直覺，但這實際上是一種回滾方法。 它基本上做你認為--iterative-rollback會做的事情，但工作更頻繁。
• 在 AWS 控制台中，go 到您環境的部署存儲桶（存儲桶將命名為amplify-${project_name}-${environment_name}-${some_random_numbers}-deployment ）。 如果有一個名為deployment-state.json的文件，請將其刪除並再次嘗試從 CLI amplify push 。

慢速選項（生產友好）

希望你還沒有走到這一步，但此時我建議你在amplify-cli GitHub中打開一張票，盡可能多地提供信息。 他們往往會在 1-2 個工作日內回復。

如果您是預生產，或者您在非生產環境中遇到問題，您還可以嘗試在 Amplify 控制台中克隆后端環境，並查看是否可以讓堆棧從那里開始工作。 如果是這樣，那么您可以使用amplify env checkout ${your_old_env_name}然后amplify push將固定部署推回之前的環境（如果您願意）。

復雜選項（解決堆棧中更復雜的問題）

如果以上方法均無效（或者您沒有時間等待對 GitHub 問題的響應），請轉到 AWS 控制台中的 CloudFormation 並搜索堆棧中出錯的部分。 有幾種不同的方法可以做到這一點：

1. 檢查最后一次推送的 CLI output 並找到狀態不是UPDATE_COMPLETE的項目。 您可以復制堆棧的名稱並在 CloudFormation 中搜索它。
2. 在 CloudFormation 中搜索您的環境名稱，單擊任何結果堆棧，單擊Parent stack下的鏈接，重復直到找到沒有父堆棧的堆棧。 您現在位於部署的根堆棧中，有兩種方法可以從這里找到您的錯誤堆棧：
   • 單擊Resources選項卡，找到狀態欄中帶有紅色內容的資源。 Select 來自這一行的堆棧。
   • 單擊“ Events ”選項卡，找到狀態欄中帶有紅色內容的事件。 Select 來自這一行的堆棧。
3. 找到損壞的堆棧后，單擊Stack actions按鈕和 select 從下拉菜單中Detect drift 。
4. 再次單擊Stack actions按鈕，然后從下拉菜單中單擊 select View drift results 。
5. 在Resource drift results頁面中，您將看到堆棧中的資源列表。 如果其中任何一個在Drift status列中顯示漂移， DRIFTED該項目左側的單選按鈕，然后單擊View drift details按鈕。 漂移詳細信息將在下一頁並排顯示，git 樣式。 您還可以單擊上面列表中的復選框以突出顯示漂移更改。 保持當前頁面打開，稍后您將需要它。
6. 修復偏差將取決於它是什么——它通常是 IAM 策略中發生更改的內容，您可以直接在控制台中修復它。 有時它是 Lambda function 上缺少的環境變量，您最好在 CLI 中進行修復（在這種情況下，您需要再次運行amplify push並等待構建完成，以便將修復程序部署到您的環境）。
7. 修復漂移后，您可以單擊頁面頂部的橙色Detect stack drift按鈕，它會更新。 希望你已經解決了這個問題。

GraphQL 獎金回合（完全是香蕉 DDB 漂移）

Amplify 不時做的另一件有趣的事情是（看似自發地）更改部分或全部 DynamoDB 表定義的服務器端加密設置，您甚至無需觸及它。 這是迄今為止我遇到的最奇怪的 Amplify 錯誤（這說明了一些事情）！

我對此有一種解決方法，即打開amplify/backend/api/${your_api_name}/parameters.json並將DynamoDBEnableServerSideEncryption設置從false更改為true ，保存它，然后運行amplify push 。 這將失敗。 但這沒關系，因為這樣你就可以撤銷更改（將其設置回false ），保存它，再次按下，瞧。 我仍然無法終生理解這是如何或為什么會發生的。

我說這是一種修復，那是因為您仍然會看到在 CloudFormation 中部署受影響表的堆棧存在偏差。 這會在一段時間后消失。 同樣，我不知道如何或為什么。

核選項（不要在生產中使用）

顯然，這個帶有一個巨大的免責聲明：不要在生產中這樣做。 如果使用任何類型的數據庫，您將丟失數據。

您可以對所有內容進行備份，然后開始一次刪除一個有問題的資源，並在每個資源之間進行amplify push ，直到堆棧構建成功。 構建完成后，您可以開始重新添加資源。

希望這對某人有所幫助，請隨時提出修改建議或其他解決方案。

Answer 2

這對我有用：

$ amplify update auth

選擇“是，使用默認配置”選項（使用 Cognito 身份池）。

然后：

$ amplify push

另一個原因可能是這個

該問題與此選項的選擇有關 - Select 您要使用的身份驗證/授權服務： User Sign-Up & Sign-In only (Best used with a cloud API only)創建 UserPool 而不是 IdentityPool rootstack 正在尋找的。 這是一個錯誤，我們會修復它。

要取消阻止，僅針對第一個問題，您可以 select - ❯ User Sign-Up, Sign-In, connected with AWS IAM controls (Enables per-user Storage features for images or other content, Analytics, and more) ，這將創建一個用戶池以及身份池，然后選擇您上面提到的任何其他配置。

Answer 3

您可以嘗試如下

先做

amplify env checkout {environment}然后

amplify push

Answer 4

正如此線程中的其他人所提到的 - 問題來自您在本地更新的資源之一。

檢查您修改了哪些：

$ amplify status

然后remove並再次add它，然后是push 。 已知Api目前無法使用更新，因此如果您在本地進行了更改，則必須將其刪除：

$ amplify api remove YourAPIName
$ amplify api add
$ amplify push

Answer 5

在我看來，這類問題總是與 3rd 方身份驗證有關。

• 放大更新授權，
• 然后更新身份驗證流第 3 方的 id 和 secret。
• 然后推。

它將解決問題

Answer 6

解決方案是：

一個。 Go 到包含項目設置的 s3 存儲桶。

灣。 在根文件夾中找到deployment-state.json文件並將其刪除。

c。 amplify push

Answer 7

在對我的 GraphQL 模式進行一些修改后，我得到了這個。 我調整了在幾張桌子上制作@connection 指令的方式。 我可以通過以下步驟解決此問題：-

1. 制作您嘗試推送的新架構的備份副本
2. 運行amplify pull以恢復您的本地以與雲中的后端同步。
3. 完成后，您應該將本地同步到雲端，並且amplify push應該可以正常工作，因為它已同步到雲端並且應該沒有更新。
4. 將新架構復制到拉取的架構上，並嘗試再次運行amplify push以查看它是否有效。

如果它不起作用，請撤消對拉取架構的覆蓋，並比較拉取架構與您備份的更新架構之間的不同之處。 逐行進行 diffcheck 並查看發生了什么變化，並嘗試逐個推送更改以查看失敗的地方。 我認為不要一次對架構進行太多更改是更明智的做法。 一件一件地做，以便您可以更輕松地進行故障排除。 如果您確實有其他問題，那么它應該與這個問題中突出顯示的問題無關，因為拉動應該解決這個特定問題。

Answer 8

在我的情況下，問題是由於引用 GSI 的多個@connections ，當我執行放大推送 api 時，它們沒有被刪除和正確添加。

我可以通過amplify pull來解決這個問題，然后注釋掉@connection ，然后將 GSI 鏈接到連接，然后手動添加每個新的更改，但是 GSI 再次鏈接時遇到了麻煩，因為本地更新認為 GSI 已經刪除但在雲它似乎被保留了，我得到一個錯誤，正在添加一個已經在雲中的 GSI。 所以我重命名了 model 名稱，所以它被重新創建為 dynamoDB 中的新表，然后我將其恢復為正確的名稱。 這對於沒有太大影響的開發環境是理想的。

但當然它占用了我大部分時間，但它確實解決了我的問題。

Answer 9

在我的情況下，在放大 env（結帳）之間切換時出現問題，錯誤尚不清楚，但這是我為修復它所做的，而無需“清除”api 並丟失整個數據庫：

• 通過在“amplify/backend/api//parameters.json”中將“CreateAPIKey”設置為“0”來刪除現有的API Key，然后保存文件並執行“amplify push”。
• 完成后，將“CreateAPIKey”設置為“1”然后“放大推送”執行相同的過程。 這解決了我的問題。

Answer 10

我通過執行以下操作調試了我的 AWS Amplify CLI 推送錯誤：

1. 打開CloudFormation
2. 查找具有名稱的父堆棧，例如： amplify-companyName-envName-123456
3. 單擊Events選項卡
4. 向下滾動直到找到UPDATE_FAILED ，它應該會詳細說明失敗的原因。 例如The following resource(s) failed to create: ...

或者（查找父堆棧）：

1. 導航到 AWS Amplify 站點中的環境， Overview選項卡
2. 單擊View in CloudFormation
3. 在Stack info選項卡下，單擊Parent stack的鏈接
4. 在父頁面上，單擊Events選項卡

Answer 11

這對我有用

amplify remove storage

接着

amplify add storage

然后，再一次

amplify push

在amplify add storage之后，我錯誤地選擇了 Y 是否要為您的 S3 存儲桶添加 Lambda 觸發器？ 我沒有任何 Lamda function，我的桶里也沒有任何東西。

Answer 12

它看起來像后端和本地之間的沖突

唯一對我有用的是備份本地模式並啟動放大拉取命令。

然后使用備份模式文件並初始化放大推送。

在大多數情況下，必須手動設置以下文件中的更新（對於 Android）：app/src/main/res/raw/amplifyconfiguration.json