Bekannte Probleme mit Workflows

Unerwartetes Verhalten, betriebliche Einschränkungen und verfügbare Problemumgehungen können sich auf die Ausführung von Workflows und Connectors auswirken. 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, tritt ein Fehler auf. Ein einzelner Schritt kann beispielsweise direkt nach try platziert werden:

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

Wenn Sie for jedoch 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)

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-Meldung 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 eine Wiederholungsrichtlinie oder eine explizite Ausnahmebehandlung implementieren.

Anrufliste und accessString-Methode zum Abrufen vertraulicher Daten

Wenn die Anruflogging-Stufe auf log-all-calls festgelegt ist, wenn die Hilfsmethode accessString zum Abrufen geheimer Daten verwendet wird, wird der geheime Wert nicht unkenntlich gemacht, sondern im Klartext in die Logs in jsonPayload.succeeded.response geschrieben.

Ausnahme für Vorgänge 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 ähnlich der folgenden 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, legen Sie den Connector-Parameter skip_polling auf true fest, 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ützt keine HTTP-Anfragen an die IP-basierten Endpunkte von GKE-Cluster-Steuerungsebenen mehr. Weitere Informationen zum Umfang und zu den Auswirkungen dieser Einstellung finden Sie in der Servicemitteilung.

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

Strategien zur Fehlerbehebung