Bekannte Probleme bei Workflows

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.