Problemi noti per Workflows

Questa pagina elenca i problemi noti di Workflows.

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 va a buon fine 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 attiveranno l'esecuzione del flusso di lavoro. Per ulteriori informazioni, consulta Quote e limiti.

Messaggio HTTP request lost 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 flusso di lavoro implementando un criterio di ripetizione o tramite la gestione esplicita delle eccezioni.

Logging delle chiamate e metodo accessString per recuperare i dati secret

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

Eccezione di operazione di lunga durata durante l'utilizzo del 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; altrimenti, per rilevare eventuali eccezioni, utilizza una struttura try/except. Per saperne di più, consulta il 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 maggiori informazioni, 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 del 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.