Questa pagina elenca i problemi noti relativi a Workflows.
Puoi anche verificare la presenza di problemi esistenti o aprirne di nuovi negli Issue Tracker pubblici.
Posizionamento di for direttamente dopo try
Se posizioni for direttamente dopo try, si verifica un errore. Ad esempio, un singolo passaggio
può essere inserito direttamente dopo try, come questo:
- 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 superiori alla dimensione massima degli argomenti
Se utilizzi Workflows come destinazione per un trigger Eventarc, gli eventi superiori alla dimensione massima degli argomenti di Workflows non attiveranno le esecuzioni del flusso di lavoro. Per maggiori 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 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 riscontri questo errore, prova a modificare il flusso di lavoro implementando un criterio di nuovo tentativo o tramite una gestione delle eccezioni esplicita.
Registrazione delle chiamate e metodo accessString per recuperare i dati secret
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 del secret non viene oscurato e viene stampato in testo normale nei log in jsonPayload.succeeded.response.
Eccezione per un'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 andata a buon fine, 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 chiamata del connettore non blocchi se la richiesta iniziale ha esito positivo. Una richiesta andata a buon fine restituisce "done":true. In caso contrario, per rilevare eventuali eccezioni, utilizza una struttura try/except.
Per ulteriori informazioni, consulta la documentazione di riferimento sui connettori.
Passaggi successivi
Scopri strategie utili per risolvere i problemi.