Problemi noti di Workflows

Questa pagina elenca i problemi noti di Workflows.

Puoi anche controllare se esistono 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 può essere posizionato 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 è aggiungere un passaggio con nome 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 maggiori della dimensione massima degli argomenti

Se utilizzi Workflows come destinazione per un Trigger Eventarc, eventi maggiori del limite massimo Le dimensioni degli argomenti di Workflows non attiveranno il flusso di lavoro eseguite. Per ulteriori informazioni, consulta Quote e limiti.

HTTP request lost messaggio nei log

Durante l'esecuzione di un flusso di lavoro che chiama Cloud Build, il flusso di lavoro non riesce 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 si verifica questo errore, prova a modificare il flusso di lavoro implementando un riprova di volta in volta o tramite esplicita gestione delle eccezioni.

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 per operazioni a lunga esecuzione quando si utilizza il connettore Cloud Resource Manager

Il metodo del connettore Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, non restituisce il nome di un'operazione a lunga esecuzione (LRO). Anche per una 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 Informazioni sui connettori.

Passaggi successivi

Scopri le strategie utili per la risoluzione dei problemi.