Problembehandlung bei Snowpark Container Services¶

Fehler „invalid consent request“ (ungültige Zustimmungsanforderung) beim Zugriff auf einen öffentlichen Dienstendpunkt.

In der aktuellen Implementierung authentifiziert Snowflake den aktuellen Benutzer anhand seiner Standardrolle. Ursache des Fehlers ist wahrscheinlich, dass der Benutzer eine der Rollen mit umfangreichen Berechtigung, wie ACCOUNTADMIN oder SECURITYADMIN, als Standardrolle verwendet (siehe Blockieren bestimmter Rollen für die Verwendung der Integration). Verwenden Sie den Befehl ALTER USER, um die Standardrolle für den Benutzer zu ändern, und versuchen Sie es erneut.

docker login-Authentifizierungsfehler.

Verwenden Sie im Befehl docker login keinen Hostnamen in Großbuchstaben und dann im Befehl docker push, docker pull einen Hostnamen in Kleinbuchstaben. Die Docker-CLI speichert Anmeldeinformationen exakt wie eingegeben (also unter Berücksichtigung der Groß-/Kleinschreibung). Verwandtes Docker-CLI-Problem.

docker push-Fehler: Kein Host in Anforderungs-URL.

Wenn Sie mit der Docker-CLI interagieren, müssen Sie die Unterstriche in Ihrem Kontonamen in einer URL immer durch Bindestriche ersetzten. Die Docker-CLI gibt einen Fehler zurück, wenn Hostnamen Unterstriche enthalten (auch wenn cURL funktioniert). Im folgenden Docker-Push wird zum Beispiel „my_acct“ als Kontoname angegeben:

docker push myorg-my_acct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/service_to_service

Docker gibt folgenden Fehler zurück:

Get "https:/v2/": http: no Host in request URL.

Sie können auch den Befehl SHOW IMAGE REPOSITORIES verwenden, um eine gültige Repository-URL zu erhalten.

Angehaltener Computepool steckt im Status STOPPING fest.

Das Ausführen von Diensten verhindert, dass der Computepool angehalten wird. Halten Sie alle verbliebenen aktiven Dienste im Computepool mit dem Befehl ALTER COMPUTE POOL an:

ALTER COMPUTE POOL <pool_name> STOP ALL

Ein aktiver Dienst antwortet nicht mehr auf Anforderungen (von einer Dienstfunktion oder einem öffentlichen Endpunkt). Der Status des Dienstes wurde von „Aktiv“ in „Ausstehend“ geändert.

Dies könnte ein Anzeichen für einen Ressourcenmangel auf den Computepool-Knoten sein. Wenn Ihre Container ressourcenintensiv (CPU/Arbeitsspeicher) sind, sollten Sie in der Dienstspezifikation explizit Ressourcenanforderungen angeben, um zu verhindern, dass zu viele Dienste (einschließlich Jobdienste) auf einem einzigen Knoten platziert werden.

In der derzeitigen Implementierung können Sie nur Anforderungen hinsichtlich des Arbeitsspeichers spezifizieren.

Wenn ein Knoten im Computepool beispielsweise 64 GB RAM hat, würde die Anforderung von mehr als 32 GB für Ihren Dienst (oder Jobdienst) garantieren, dass nur ein Dienst oder ein oder Jobdienst gleichzeitig auf einem Knoten ausgeführt werden kann. Weitere Informationen zu den Fähigkeiten der einzelnen Instanztypen finden Sie unter CREATE COMPUTE POOL.

Wenn Sie eine Anforderung an den öffentlichen Endpunkt des Dienstes übermitteln, verwenden Sie im HTTP-Authentifizierungsheader keine Anführungszeichen.

Probleme mit Timeouts und doppelter Ausführung bei Dienstfunktionen.

Wenn ein einzelner Aufruf einer Dienstfunktion länger als 30 Sekunden dauert, versucht Snowflake die Funktion erneut auszurufen, und nach einigen Wiederholungen schlägt die Funktion mit einem Timeout-Fehler fehl. Sie könnten unerwartete Ergebnisse erhalten, wenn die Funktionsimplementierung im Container nicht idempotent ist. Ziehen Sie die asynchrone Ausführung in Betracht, indem Sie einen anderen HTTP-Code (202) zurückgeben, der ein längeres Timeout erlaubt. Weitere Informationen dazu finden Sie unter Asynchroner Remotedienst.

Wenn die Authentifizierung fehlschlägt, kann dies an der Netzwerkrichtlinie liegen, die mit dem Benutzer oder Konto verknüpft ist.

Wenn Sie vom Internet aus auf den öffentlichen Endpunkt zugreifen, kann es sein, dass die Authentifizierung mit Benutzername und Kennwort funktioniert, aber SSO zu einer leeren Seite oder dem Fehler führt: „OAuth Clientintegration mit der angegebenen Client-ID wurde nicht gefunden.“ Informationen zum Umgang mit diesem Problem finden Sie unter Überlegungen zum Zugriff und SSO.

Wenn ein Client einen 5XX-Fehler von einem Eingangsendpunkt (500/503/504) erhält, sollte der Client es erneut versuchen, mit einer gewissen Verzögerung. Wir empfehlen begrenztes exponentielles Backoff.

Eine CORS-Preflight-Anfrage gibt den Status 404-Endpunkt existiert nicht zurück:

Prüfen Sie, ob der Endpunkt existiert, indem Sie den Befehl SHOW ENDPOINTS ausführen.

Eine CORS-Preflight-Anfrage gibt den Status 302 zurück.

Die CORS-Anfrage enthielt keine Form der Authentifizierung. Da wir nicht zwischen CORS-Anfragen und Weiterleitungen/Anker-Tags unterscheiden können, müssen wir davon ausgehen, dass es sich um eine Weiterleitung/Anker-Tag handelt und geben ein 302 zurück.

Antwortstatus 403 „Ablehnung einer CORS-Anfrage, da ein Cookie vorhanden war und die Anfrage keinen Auth-Header hat“.

Dies tritt auf, wenn eine herkunftsübergreifende nicht-GET nicht-HEAD-Anfrage versucht, ein Cookie als Authentifizierungsmethode zu verwenden. Der Authentifizierungs-Header ist für diese herkunftsübergreifenden Anfragen erforderlich. Dieser Fehler tritt auf, wenn die Anfrage Cookies enthält und der Authentifizierungs-Header nicht vorhanden ist.

Fehlermeldung „Herkunftsübergreifende Anfrage blockiert: Die Same Origin Policy verbietet das Lesen der Remote-Ressource unter …“.

Der Browser gibt diesen Fehler zurück, wenn der Dienst angibt, dass er den angeforderten herkunftsübergreifenden Zugriff nicht unterstützt. Dies geschieht in der Regel, weil die vom Browser bereitgestellte Origin nicht mit einem der unter Access-Control-Allow-Origin in der Dienstspezifikation für den Endpunkt angegebenen Ursprünge übereinstimmt. Damit diese übereinstimmen, müssen sowohl das Schema (HTTP/HTTPS) als auch der Hostname übereinstimmen.