Bekannte Probleme bei 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“

Die Platzierung von „for“ direkt nach „try“ verursacht einen Fehler. Ein einzelner Schritt kann 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 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 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 angezeigt, die etwa so aussieht:

[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 ein Wiederholungsrichtlinie oder durch explizite Handhabung von Ausnahmen.

Anrufprotokollierung und accessString-Methode zum Abrufen geheimer Daten

Wenn die Call Logging level ist festgelegt auf log-all-calls wenn mithilfe der Hilfsmethode accessString zum Abrufen von Secret-Daten, Der Secret-Wert wird nicht entfernt und als Klartext an die jsonPayload.succeeded.response

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. Eine erfolgreiche Die Anfrage gibt "done":true zurück. Andernfalls verwenden Sie zum Erkennen von Ausnahmen einen try/except-Struktur. Weitere Informationen finden Sie in der Referenz zu Connectors.

Nächste Schritte

Informationen zur Fehlerbehebung