Problemi noti per Workflows

Comportamenti imprevisti, limitazioni operative e soluzioni alternative disponibili possono influire sulle esecuzioni di Workflows e sui connettori. Puoi anche verificare la presenza di problemi esistenti o aprirne di nuovi negli strumenti Issue Tracker pubblici.

Posizionamento di for subito dopo try

L'inserimento di for subito dopo try causa un errore. Ad esempio, un singolo passaggio può essere inserito direttamente dopo try, in questo modo:

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

Tuttavia, se posizioni for dopo try, il passaggio non riesce e non puoi eseguire il deployment del flusso di lavoro. Ad esempio:

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

Il messaggio di errore è il seguente:

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

La soluzione alternativa consiste nell'aggiungere un passaggio denominato dopo try. Ad esempio:

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

Eventi più grandi della dimensione massima degli argomenti

Se utilizzi Workflows come destinazione per un trigger Eventarc, gli eventi più grandi della dimensione massima degli argomenti di Workflows non riusciranno ad attivare l'esecuzione del flusso di lavoro. Per saperne di più, consulta Quote e limiti.

HTTP request lost messaggio nei log

Quando esegui un flusso di lavoro che chiama Cloud Build, il flusso di lavoro non va a buon fine e nei log viene visualizzato un messaggio HTTP request lost simile al seguente:

[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

Se si verifica questo errore, prova a modificare il workflow implementando una policy di ripetizione o tramite la gestione esplicita delle eccezioni.

Registri chiamate e metodo accessString per recuperare i dati segreti

Se il livello di logging delle chiamate è impostato su log-all-calls quando si utilizza il metodo helper accessString per recuperare i dati secret, il valore secret non viene oscurato e viene stampato in testo normale nei log in jsonPayload.succeeded.response.

Eccezione di operazione a lunga esecuzione quando si utilizza il connettore Cloud Resource Manager

Il metodo del connettore Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, non restituisce un nome di operazione a lunga esecuzione (LRO). Anche per una richiesta riuscita, potrebbe essere generata un'eccezione simile alla seguente:

exception: "{"message":"Long-running operation returned unexpected response.",
"operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project",
...
"tags":["ResponseTypeError"]}"

Per evitare un errore di polling LRO, imposta il parametro del connettore skip_polling su true in modo che la chiamata di invocazione del connettore non sia bloccante se la richiesta iniziale va a buon fine. Una richiesta andata a buon fine restituisce "done":true; in caso contrario, per rilevare eventuali eccezioni, utilizza una struttura try/except. Per saperne di più, consulta Riferimento ai connettori.

Richieste HTTP a Google Kubernetes Engine (GKE)

Ogni cluster GKE ha un control plane che gestisce le richieste dell'API Kubernetes. Il control plane ha due tipi di endpoint per l'accesso al cluster: endpoint basati su DNS ed endpoint basati su IP. Per saperne di più, consulta Accesso al control plane.

Workflows non supporta più le richieste HTTP agli endpoint basati su IP dei control plane dei cluster GKE. Per ulteriori informazioni sull'ambito e sull'impatto di questo ritiro, consulta l'annuncio di servizio.

Per assicurarti che il flusso di lavoro funzioni come previsto, devi accedere agli endpoint basati su DNS. Per accedere agli endpoint basati su DNS, ti consigliamo di utilizzare il connettore API Kubernetes in un flusso di lavoro. Per ulteriori informazioni, consulta Accedere agli oggetti API Kubernetes utilizzando un connettore.

Passaggi successivi

Scopri le strategie utili per risolvere i problemi.