我對 Amazon Simple Queue Service (Amazon SQS) 佇列發出了 API 呼叫,但收到「QueueDoesNotExist」錯誤。
解決方法
某些 Amazon SQS API 呼叫 (例如 GetQueueAttributes、SendMessage 和 DeleteMessage) 可能會導致 QueueDoesNotExist 錯誤。若要疑難排解此錯誤,請遵循以下步驟。
檢查佇列網址是否正確
檢查請求中提供的佇列網址是否正確,且不包含錯字。
**重要:**如果目的地佇列類型是先進先出 (FIFO),則您必須在佇列網址後方附加 .fifo 字尾。
設定正確的區域
當請求傳送到不正確的 AWS 區域時,您會收到 QueueDoesNotExist 錯誤。SDK 和 AWS Command Line Interface (AWS CLI) 不會從佇列網址取得目的地區域。相反地,用戶端組態會設定區域。
在您進行 API 呼叫之前,請在 Amazon SQS 用戶端上設定正確的區域。檢閱 Amazon SQS 用戶端組態,以確認您已在用戶端上設定正確的區域。當您未在用戶端上設定區域時,SDK 或 AWS CLI 會從組態檔或環境變數中選擇區域。當 SDK 在組態檔中找不到區域時,SDK 預設會將區域設定為 us-east-1。
如需更多資訊,請參閱 AWS 區域和組態與憑證檔案設定。
如果 AWS CloudTrail 支援失敗的 API 呼叫,請檢查 AWS 帳戶中的所有區域,以尋找失敗的 Amazon SQS 操作。這有助於判斷區域是否為問題的原因。
您也可以在 SDK 或 AWS CLI 上啟用偵錯日誌,以檢查請求的區域。偵錯日誌會顯示請求的目的地主機,例如: Host: sqs.us-east-1.amazonaws.com.
以下是其他偵錯日誌資源:
**注意:**若要驗證區域、帳戶或佇列名稱,請務必記錄完整的佇列詳細資訊。
檢查最近刪除的佇列
當最近刪除佇列時,您可能會收到 QueueDoesNotExist 錯誤。識別失敗 API 呼叫的時間戳記,然後在 CloudTrail 中檢查錯誤發生時是否有任何 PurgeQueue 操作。訊息刪除程序最多需要 60 秒。
當佇列是 AWS CloudFormation 或其他部署堆疊的一部分,而且已刪除該佇列時,也可能會發生此錯誤。堆疊更新或刪除可能會導致佇列遭到刪除並重新建立。如果您在刪除時對佇列進行 API 呼叫,則請求可能會失敗。檢查 CloudTrail 中錯誤發生時是否有任何 DeleteQueue 操作。
使用 GetQueueUrl 時指定目的地佇列帳戶號碼
對於 API 呼叫,SDK 或 AWS CLI 通常會從佇列網址取得目的地佇列帳戶號碼。但是,GetQueueUrl API 呼叫不會在請求中提供佇列的帳戶,因此請求預設會針對呼叫者帳戶進行。
如果請求是針對跨帳戶佇列,則您必須將目的地佇列帳戶號碼指定為 API 呼叫的 QueueOwnerAWSAccountId 參數。
刪除在逾時期間內移至 DLQ 的訊息
對於設定了無效字母佇列 (DLQ) 的標準 SQS 佇列,重試後訊息會移至 DLQ。訊息移至 DLQ 後,當您使用主佇列中的舊 ReceiptHandle 執行 DeleteMessage 操作時,可能會發生 QueueDoesNotExist 錯誤。您必須在設定的 VisibilityTimeout 期間內刪除訊息。
確認請求者具有所需的 IAM 權限
如果提出請求的 AWS Identity and Access Management (IAM) 使用者或角色沒有必要的權限,則您可能會收到以下錯誤: 「The specified queue does not exist or you do not have access to it.」
使用 GetCallerIdentity API 呼叫確認 IAM 實體具有必要的權限。
Boto3 Python 中的 GetCallerIdentity API 呼叫範例:
import boto3
sts = boto3.client('sts')
print(sts.get_caller_identity())
如需 Amazon SQS 政策範例,請參閱 Amazon SQS 政策的基本範例。
如需 Amazon SQS 權限的更多資訊,請參閱我需要哪些權限才能存取 Amazon SQS 佇列?
使用 AWS Support 進行疑難排解
如果上述疑難排解步驟無法解決您的問題,請聯絡 AWS Support。請包含失敗 API 呼叫的 RequestId 和 timestamp 以及 timezone。