Problemi noti per Workflows

Questa pagina elenca i problemi noti di Workflows.

Puoi anche controllare se sono presenti problemi esistenti o aprirne di nuovi negli issue tracker pubblici.

Posizionamento di for direttamente dopo try

Se inserisci for direttamente dopo try, si verifica un errore. Ad esempio, un singolo passaggio puoi essere inserito direttamente dopo try, come segue:

- 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 delle dimensioni massime degli argomenti Workflows non attiveranno le esecuzioni 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 è presente 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 riscontri questo errore, prova a modificare il flusso di lavoro implementando un criterio di nuovo tentativo o tramite la gestione delle eccezioni esplicita.

Logging delle chiamate e metodo accessString per recuperare i dati dei secret

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

Eccezione di operazione a lungo termine 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 sollevata 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 esecuzione del connettore non sia bloccante se la richiesta iniziale va a buon fine. Una richiesta riuscita restituisce "done":true; in caso contrario, per rilevare eventuali eccezioni, utilizza una struttura try/except. Per ulteriori informazioni, consulta la documentazione di riferimento dei connettori.

Richieste HTTP a Google Kubernetes Engine (GKE)

Ogni cluster GKE ha un piano di controllo 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 ulteriori informazioni, consulta Accesso al piano di controllo.

Workflows non supporta richieste HTTP agli endpoint basati su IP dei control plane dei cluster GKE. Per assicurarti che il flusso di lavoro funzioni come previsto, devi accedere agli endpoint basati su DNS. Per ulteriori informazioni sull'ambito e sull'impatto, consulta l'annuncio del servizio.

Come best practice, ti consigliamo di utilizzare il connettore dell'API Kubernetes in un flusso di lavoro anziché effettuare una chiamata HTTP diretta. Per ulteriori informazioni, consulta Accedere agli oggetti dell'API Kubernetes utilizzando un connettore.

Passaggi successivi

Scopri le strategie utili per la risoluzione dei problemi.