Bekannte Probleme mit Workflows

Auf dieser Seite sind 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 sieht so aus:

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

Als Problemumgehung können Sie nach der try einen benannten Schritt 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 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 Workflowausführungen aus. Weitere Informationen finden Sie unter Kontingente und Limits.

HTTP request lost-Nachricht in den Protokollen

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, ändern Sie Ihren Workflow. Implementieren Sie dazu entweder eine Wiederholungsrichtlinie oder eine explizite Ausnahmebehandlung.

Anrufprotokollierung und accessString-Methode zum Abrufen geheimer Daten

Wenn die Ebene der Anrufprotokollierung auf log-all-calls festgelegt ist, wenn die Hilfsmethode accessString zum Abrufen geheimer Daten verwendet wird, wird der geheime Wert nicht entfernt und in den Protokollen in jsonPayload.succeeded.response im Klartext ausgegeben.

Ausnahme für lang andauernde Vorgänge 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. Auch bei einer erfolgreichen Anfrage kann eine Ausnahme wie die folgende auftreten:

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, legen Sie den Connector-Parameter skip_polling auf true fest, damit der Aufruf des Connectors nicht blockiert wird, wenn die erste Anfrage erfolgreich ist. Bei einer erfolgreichen Anfrage wird "done":true zurückgegeben. Andernfalls kannst du mit einer try/except-Struktur Ausnahmen abfangen. Weitere Informationen finden Sie in der Referenz zu Connectors.

Nächste Schritte

Informationen zur Fehlerbehebung