Auf dieser Seite werden bekannte Probleme für Workflows aufgeführt.
Außerdem können Sie in der öffentlichen Problemverfolgung prüfen, ob Probleme vorhanden sind, und neue Probleme eröffnen.
Platzierung von for
direkt nach try
Wenn Sie for
direkt nach try
platzieren, verursacht dies einen Fehler. Beispielsweise kann ein einzelner Schritt direkt nach try
platziert werden:
- try: try: call: sys.log args: data: works retry: ${http.default_retry}
Wenn Sie jedoch for
nach try
positionieren, schlägt der Schritt fehl und Sie können den Workflow nicht bereitstellen. Beispiel:
- try: try: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
Die Fehlermeldung lautet:
Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)
Sie können das Problem umgehen, indem Sie einen benannten Schritt nach try
hinzufügen. Beispiel:
- try: try: steps: - loopStep: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
Ereignisse, die größer sind als die maximale Argumentgröße
Wenn Sie Workflows als Ziel für einen Eventarc-Trigger verwenden, können Ereignisse, die größer als die maximale Größe von Workflow-Argumenten sind, keine Workflowausführungen auslösen. Weitere Informationen finden Sie unter Kontingente und Limits.
HTTP request lost
Nachricht in Logs
Beim Ausführen eines Workflows, der Cloud Build aufruft, schlägt der Workflow fehl und in den Logs wird eine HTTP request lost
-Meldung ähnlich der folgenden angezeigt:
[1500] HTTP request lost INTERNAL MESSAGE: HTTP request lost ... CAUSED BY: RPC::UNREACHABLE: RPC connection timed out: FDD 20s, last read 2022-10-14 16:39:04 -0700 PDT
Wenn dieser Fehler auftritt, können Sie den Workflow ändern. Implementieren Sie dazu entweder eine Wiederholungsrichtlinie oder verwenden Sie eine explizite Handhabung von Ausnahmen.
Aufruf-Logging und accessString
-Methode zum Abrufen von Secret-Daten
Wenn die Logging-Ebene für Aufrufe bei Verwendung der Hilfsmethode accessString
zum Abrufen von Secret-Daten auf log-all-calls
festgelegt ist, wird der Secret-Wert nicht entfernt und als Nur-Text an die Logs in jsonPayload.succeeded.response
ausgegeben.
Ausnahme für Vorgänge mit langer Ausführungszeit bei Verwendung des Cloud Resource Manager-Connectors
Die Resource Manager-Connector-Methode googleapis.cloudresourcemanager.v3.projects.patch
gibt keinen Namen für einen lang andauernden Vorgang zurück. Selbst bei einer erfolgreichen Anfrage kann eine Ausnahme wie diese ausgelöst werden:
exception: "{"message":"Long-running operation returned unexpected response.", "operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project", ... "tags":["ResponseTypeError"]}"
Um einen LRO-Abfragefehler zu vermeiden, legen Sie den Connector-Parameter skip_polling
auf true
fest, damit der Aufruf des Connector-Aufrufs nicht blockiert wird, wenn die erste Anfrage erfolgreich ist. Eine erfolgreiche Anfrage gibt "done":true
zurück. Andernfalls müssen Sie eine try/except
-Struktur verwenden, um Ausnahmen abzufangen.
Weitere Informationen finden Sie in der Referenz zu Connectors.
Nächste Schritte
Hier finden Sie hilfreiche Strategien zur Fehlerbehebung.