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

Lösung

Einige API-Aufrufe in Amazon SQS, wie GetQueueAttributes, SendMessage und DeleteMessage, können den Fehler QueueDoesNotExist verursachen. Gehen Sie wie folgt vor, um diesen Fehler zu beheben.

Überprüfen Sie, ob die URL der Warteschlange korrekt ist

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

**Wichtig:**Wenn der Typ der Zielwarteschlange First-In-First-Out (FIFO) ist, müssen Sie das Suffix .fifo an die URL der Warteschlange anhängen.

Stellen Sie die richtige Region ein

Sie erhalten den Fehler QueueDoesNotExist auch, wenn eine Anfrage an die falsche AWS-Region gestellt wird. Das SDK und das AWS Command Line Interface (AWS CLI) rufen die Zielregion nicht aus der URL der Warteschlange ab. Stattdessen legt die Client-Konfiguration die Region fest.

Bevor Sie einen API-Aufruf tätigen, legen Sie die richtige Region auf dem Amazon SQS-Client fest. Überprüfen Sie die Konfiguration des Amazon SQS-Client, um sicherzustellen, dass Sie die richtige Region auf dem Client konfiguriert haben. Wenn Sie keine Region auf dem Client konfigurieren, wählt das SDK oder das AWS CLI die Region aus der Konfigurationsdatei oder den Umgebungsvariablen aus. Wenn das SDK in der Konfigurationsdatei keine Region findet, setzt das SDK die Region standardmäßig auf us-east-1.

Weitere Informationen finden Sie unter AWS-Region und Konfiguration und Einstellungen der Anmeldeinformationen.

Wenn AWS CloudTrail den fehlgeschlagenen API-Aufruf unterstützt, überprüfen Sie alle Regionen im AWS-Konto auf den fehlgeschlagenen Vorgang von Amazon SQS. Auf diese Weise kann festgestellt werden, ob die Region die Ursache des Problems ist.

Sie können auch das Debug-Protokoll im SDK oder im AWS CLI aktivieren, um die Region der Anfrage zu überprüfen. Debug-Protokolle zeigen den Zielhost für die Anfrage, zum Beispiel: Host: sqs.us-east-1.amazonaws.com.

Hier sind zusätzliche Debug-Protokollressourcen:

• Protokollieren von AWS SDK für JavaScript-Aufrufe
• Aufruf-Protokollierung von AWS SDK für Java
• Protokollierung mit dem SDK für Java 2.x.
• Python-Protokollierungsebenen auf der Python-Website
• Protokollierung mit dem AWS SDK für.NET

**Hinweis:**Um die Region, das Konto oder den Warteschlangennamen zu überprüfen, stellen Sie sicher, dass Sie die vollständigen Warteschlangendetails protokollieren.

Suchen Sie nach einer kürzlich gelöschten Warteschlange

Möglicherweise wird ein Fehler vom Typ QueueDoesNotExist angezeigt, wenn eine Warteschlange kürzlich gelöscht wurde. Identifizieren Sie den Zeitstempel des fehlgeschlagenen API-Aufrufs und überprüfen Sie dann CloudTrail auf Operationen vom Typ PurgeQueue zum Zeitpunkt des Auftretens des Fehlers. Das Löschen von Nachrichten dauert bis zu 60 Sekunden.

Der Fehler kann auch auftreten, wenn die Warteschlange Teil einer AWS CloudFormation oder eines anderen Bereitstellungsstapels ist und die Warteschlange gelöscht wird. Stapelaktualisierungen oder Löschungen können dazu führen, dass die Warteschlange gelöscht und neu erstellt wird. Wenn Sie zum Zeitpunkt des Löschens den API-Aufruf an die Warteschlange tätigen, kann die Anfrage fehlschlagen. Überprüfen Sie CloudTrail auf Operationen vom Typ DeleteQueue zum Zeitpunkt des Auftretens des Fehlers.

Geben Sie die Kontonummer der Zielwarteschlange an, wenn Sie GetQueueUrl verwenden

Bei API-Aufrufen verwendet das SDK oder das AWS CLI normalerweise die Kontonummer der Zielwarteschlange aus der URL der Warteschlange. Der API-Aufruf GetQueueUrl beschreibt jedoch kein Konto einer Warteschlange in der Anfrage, sodass die Anfrage standardmäßig für das Konto des Aufrufenden gestellt wird.

Wenn die Anfrage für eine kontoübergreifende Warteschlange vorgesehen ist, müssen Sie die Kontonummer der Zielwarteschlange als den API-Aufruf QueueOwnerAWSAccountId angeben.

Löschen von Nachrichten, die innerhalb des Timeout-Fensters in eine DLQ verschoben wurden

Bei Standard-SQS-Warteschlangen, die mit einer Warteschlange für unzustellbare Nachrichten (DLQ) konfiguriert sind, werden Nachrichten nach Wiederholungen in die DLQ verschoben. Nachdem die Nachricht in die DLQ verschoben wurde, kann der Fehler QueueDoesNotExist auftreten, wenn Sie einen Vorgang vom Typ DeleteMessage mit einem alten ReceiptHandle aus der Hauptwarteschlange ausführen. Sie müssen Nachrichten innerhalb des unter VisibilityTimeout konfigurierten Zeitfensters löschen.

Stellen Sie sicher, dass der Aufrufende über die erforderlichen IAM-Berechtigungen verfügt

Wenn der anfragende Benutzer oder die anfragende Rolle von AWS Identity and Access Management (IAM) nicht über die erforderlichen Berechtigungen verfügt, wird möglicherweise die folgende Fehlermeldung angezeigt: "Die angegebene Warteschlange existiert nicht oder Sie haben keinen Zugriff darauf."

Verwenden Sie den API-Aufruf GetCallerIdentity, um zu überprüfen, ob die IAM-Entität über die erforderlichen Berechtigungen verfügt.

Beispiel für API-Aufruf vom Typ GetCallerIdentity in Boto3 Python:

import boto3
sts = boto3.client('sts')
print(sts.get_caller_identity())

Beispiele für Amazon SQS-Richtlinien finden Sie unter Grundlegende Beispiele für Amazon SQS-Richtlinien.

Weitere Informationen zu Amazon SQS-Berechtigungen finden Sie unter Welche Berechtigungen benötige ich für den Zugriff auf eine Amazon SQS-Warteschlange?

Problembehebung mit AWS Support

Wenn die vorherigen Schritte zur Fehlerbehebung Ihr Problem nicht lösen, wenden Sie sich an den AWS-Support. Fügen Sie die RequestId und den Zeitstempel mit der Zeitzone der fehlgeschlagenen API-Aufrufe hinzu.