Wie behebe ich QueueDoesNotExist-Fehler, wenn ich API-Aufrufe an meine Amazon-SQS-Warteschlange tätige?

Letzte Aktualisierung: 24.08.2021

Wenn ich API-Aufrufe an meine Warteschlange für Amazon Simple Queue Service (Amazon SQS) mache, erhalte ich einen QueueDoesNotExist-Fehler ähnlich dem folgenden:

„Die angegebene Warteschlange existiert nicht für diese WSDL-Version.“

Warum erhalte ich diesen Fehler und wie kann ich das Problem beheben?

Lösung

QueueDoesNotExist-Fehler können aus verschiedenen Amazon-SQS-API-Aufrufen resultieren, einschließlich GetQueueAttributes, SendMessage und DeleteMessage. Um diesen Fehler zu beheben, überprüfen Sie die folgenden möglichen Ursachen und Lösungsschritte:

Falsche Warteschlangen-URL

Stellen Sie sicher, dass die in der Anfrage angegebene Warteschlangen-URL korrekt ist und keine Tippfehler enthält.

Wichtig: Wenn der Typ der Zielwarteschlange FIFO ist, müssen Sie das Suffix .fifo an die Warteschlangen-URL anhängen.

Falsche Region

Eine QueueDoesNotExist-Ausnahme wird zurückgegeben, wenn die Anforderung an die falsche AWS-Region gestellt wird. Das Software Development Kit (SDK) und die AWS Command Line Interface (AWS CLI) holen die Zielregion nicht von der Warteschlangen-URL ab. Stattdessen wird die Region durch die Benutzerkonfiguration bestimmt.

Sie müssen die Region auf dem Amazon-SQS-Client korrekt konfigurieren, bevor Sie einen API-Aufruf tätigen. Überprüfen Sie die Amazon-SQS-Benutzerkonfiguration, um zu bestätigen, dass die richtige Region auf dem Benutzer konfiguriert ist. Wenn keine Region auf dem Benutzer konfiguriert ist, wählt das SDK oder AWS CLI die Region aus der Konfigurationsdatei oder der Umgebungsvariablen aus. Wenn in der Konfigurationsdatei keine Region gefunden wird, setzt das SDK die Region standardmäßig auf US-Ost-1.

Wenn der fehlgeschlagene API-Aufruf von AWS CloudTrail unterstützt wird, überprüfen Sie alle Regionen im Kundenkonto auf den fehlgeschlagenen Amazon-SQS-Vorgang. Die Überprüfung aller Regionen kann dazu beitragen, festzustellen, ob die Region die Ursache des Problems ist.

Sie können die Region der Anforderung auch überprüfen, indem Sie das Debug-Protokoll im SDK oder AWS CLI aktivieren. Debug-Protokolle zeigen den Zielhost für die Anforderung.

Beispiel: Host: sqs.us-east-1.amazonaws.com

Warteschlange wurde kürzlich bereinigt oder gelöscht

Möglicherweise erhalten Sie vorübergehend einen QueueDoesNotExist-Fehler, wenn die Warteschlange kürzlich bereinigt wurde. Identifizieren Sie den Zeitstempel des fehlgeschlagenen API-Aufrufs und überprüfen Sie dann CloudTrail für alle PurgeQueue-Vorgänge um den Zeitpunkt des Fehlers.

Der Fehler kann auch auftreten, wenn die Warteschlange gelöscht wird, wenn die Warteschlange Teil einer AWS CloudFormation oder eines ähnlichen Bereitstellungs-Stack ist. Aktualisierungen oder Löschungen eines Stacks können dazu führen, dass die Warteschlange gelöscht und neu erstellt wird. Wenn der API-Aufruf während des Löschvorgangs an die Warteschlange erfolgt, kann die Anforderung mit einem QueueDoesNotExist-Fehler fehlschlagen. Überprüfen Sie CloudTrail für alle DeleteQueue-Vorgänge während des Fehlerzeitpunkts.

Kontoübergreifend getQueueURL

Bei API-Aufrufen nimmt das SDK oder AWS CLI normalerweise die Kontonummer der Zielwarteschlange aus der Warteschlangen-URL. Der API-Aufruf getQueueUrl stellt jedoch kein AWS-Konto einer Warteschlange in der Anfrage bereit. Dies bedeutet, dass die Anfrage standardmäßig gegen das Anruferkonto gestellt wird. Wenn die Anforderung für eine kontoübergreifende Warteschlange vorgesehen ist, müssen Sie die Kontonummer der Zielwarteschlange als API-Aufruf-QueueOwnerawsAccountID-Parameter angeben.

Nachricht wurde in eine Dead-Letter-Warteschlange verschoben.

Wenn für Standard-SQS-Warteschlangen eine Dead-Letter-Warteschlange (DLQ) konfiguriert ist, werden Nachrichten nach Wiederholungsversuchen an den DLQ verschoben. QueueDoesNotExist-Fehler können auftreten, wenn Sie einen DeleteMessage-Vorgang mit einem alten ReceiptHandle aus der Hauptwarteschlange ausführen, nachdem die Nachricht in den DLQ verschoben wurde. Sie müssen Nachrichten innerhalb des konfigurierten VisibilityTimeout-Fensters löschen.

Zusätzliche Fehlerbehebung

Wenn Sie sich zur zusätzlichen Fehlerbehebung an den AWS Support wenden, müssen Sie unbedingt die RequestID und den Zeitstempel der fehlgeschlagenen API-Aufrufe identifizieren.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?