Bekannte Probleme mit Workflows

Auf dieser Seite werden bekannte Probleme mit 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, wird ein Fehler ausgegeben. Ein einzelner Schritt kann beispielsweise direkt nach try eingefügt werden:

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

Wenn Sie for jedoch nach try platzieren, 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)

Die Problemumgehung besteht darin, nach dem try einen benannten Schritt hinzuzufü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 als die maximale Argumentgröße sind

Wenn Sie Workflows als Ziel für einen Eventarc-Trigger verwenden, lösen Ereignisse, die größer als die maximale Argumentgröße von Workflows sind, keine Workflow-Ausführungen aus. Weitere Informationen finden Sie unter Kontingente und Limits.

HTTP request lost-Nachricht in Logs

Wenn Sie einen Workflow ausführen, 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, versuchen Sie, Ihren Workflow zu ändern, indem Sie entweder eine Richtlinie für Wiederholungsversuche oder eine explizite Ausnahmebehandlung implementieren.

Anruflisten und accessString-Methode zum Abrufen vertraulicher Daten

Wenn die Anruflogging-Ebene auf log-all-calls festgelegt ist, wenn die Hilfsmethode accessString zum Abrufen vertraulicher Daten verwendet wird, wird der vertrauliche Wert nicht unkenntlich gemacht, sondern im Klartext in den Logs in jsonPayload.succeeded.response ausgegeben.

Ausnahme für Vorgang mit langer Ausführungszeit bei Verwendung des Cloud Resource Manager-Connectors

Die Resource Manager-Connectormethode googleapis.cloudresourcemanager.v3.projects.patch gibt keinen Namen für einen Vorgang mit langer Ausführungszeit zurück. Auch bei einer erfolgreichen Anfrage kann eine Ausnahme wie die folgende 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-Polling-Fehler zu vermeiden, setzen Sie den Connector-Parameter skip_polling auf true, damit der Connector-Aufruf nicht blockiert wird, wenn die ursprüngliche Anfrage erfolgreich ist. Eine erfolgreiche Anfrage gibt "done":true zurück. Andernfalls verwenden Sie eine try/except-Struktur, um Ausnahmen abzufangen. Weitere Informationen finden Sie in der Referenz zu Connectors.

HTTP-Anfragen an Google Kubernetes Engine (GKE)

Jeder GKE-Cluster hat eine Steuerungsebene, die Kubernetes API-Anfragen verarbeitet. Die Steuerungsebene hat zwei Arten von Endpunkten für den Clusterzugriff: DNS-basierte Endpunkte und IP-basierte Endpunkte. Weitere Informationen finden Sie unter Zugriff auf die Steuerungsebene.

Workflows unterstützen keine HTTP-Anfragen mehr an die IP-basierten Endpunkte von GKE-Cluster-Steuerungsebenen. Weitere Informationen zum Umfang und zu den Auswirkungen dieser Einstellung finden Sie in der Dienstmitteilung.

Damit Ihr Workflow wie erwartet funktioniert, müssen Sie auf DNS-basierte Endpunkte zugreifen. Für den Zugriff auf die DNS-basierten Endpunkte empfehlen wir, den Kubernetes API-Connector in einem Workflow zu verwenden. Weitere Informationen finden Sie unter Über einen Connector auf Kubernetes API-Objekte zugreifen.

Nächste Schritte

Hier finden Sie Strategien zur Fehlerbehebung.