⏱ Wait
Mette in pausa l'esecuzione del workflow per un numero fisso di secondi prima di continuare al
passaggio successivo. Utile per il rate limiting, la distribuzione temporale delle chiamate API
e per dare ai sistemi esterni il tempo di elaborare.
Categoria: Controllo di Flusso · Identificatore tipo: wait
Panoramica
Il nodo Wait introduce una pausa deliberata nel tuo workflow. Quando l'esecuzione lo raggiunge,
Flusso mantiene l'esecuzione in attesa per il numero di secondi specificato e poi riprende con
il passaggio successivo esattamente come se nulla fosse successo. Tutte le variabili e gli
output dei passaggi precedenti alla pausa sono ancora disponibili.
I casi d'uso comuni includono:
- Rate limiting. Molte API di terze parti consentono solo un certo numero di
richieste al secondo. Posizionare un nodo Wait all'interno di un Loop aggiunge un ritardo
tra ogni iterazione per restare entro i limiti.
- Attesa di elaborazione esterna. Dopo aver avviato un job asincrono su un
sistema esterno, attendere qualche secondo prima di verificare il risultato.
- Distribuzione temporale artificiale. Nei workflow che inviano una serie di
notifiche, una breve pausa tra i messaggi può evitare i filtri antispam e migliorare
la consegnabilità.
Le attese lunghe occupano un queue worker. Mentre un nodo Wait è in pausa, il
queue worker che gestisce quell'esecuzione è occupato. Per attese superiori a 60 secondi,
considera di ristrutturare il tuo workflow: usa uno Schedule Trigger su un
workflow di follow-up, oppure dividi il lavoro su due workflow collegati da un evento.
Configurazione
| Campo |
Stato |
Descrizione |
| Seconds |
Obbligatorio |
Il numero di secondi di pausa. Deve essere un intero compreso tra 1 e 3600. Supporta i riferimenti {{ variable }} se hai bisogno di un ritardo dinamico. Ad esempio, {{ trigger.output.retry_delay }}. |
Dati di Output
| Variabile |
Tipo |
Descrizione |
waited_seconds |
integer |
Il numero effettivo di secondi di attesa del nodo. |
resumed_at |
string (ISO 8601) |
Il timestamp UTC in cui l'esecuzione è ripresa, es. 2026-03-12T14:05:30Z. |
{{ wait_step.output.waited_seconds }}
{{ wait_step.output.resumed_at }}
Esempio di Utilizzo
Chiamate API con rate limiting all'interno di un loop
Stai inviando messaggi SMS tramite un gateway che consente un massimo di un messaggio al secondo.
-
Aggiungi un nodo Loop che itera su {{ fetch.output.recipients }}.
-
All'interno del loop, aggiungi un nodo HTTP Request che chiama il gateway SMS con
{{ loop_step.current_item.phone }}.
-
Dopo l'HTTP Request, aggiungi un nodo Wait con Seconds impostato a 1.
Questo garantisce che l'iterazione successiva non inizi prima che sia trascorso almeno un secondo.
Polling di un risultato dopo l'avvio di un job lento
-
Nodo HTTP Request — POST a un servizio esterno per avviare un job in background.
La risposta contiene un job_id.
-
Nodo Wait — pausa di 10 secondi per dare al job il tempo di
completarsi.
-
Nodo HTTP Request — GET dello stato del job utilizzando
{{ start_job.output.job_id }}.
-
Nodo Logic Gate — verifica se {{ poll_job.output.status }}
è uguale a complete prima di continuare.
Suggerimenti e Note
-
Mantieni le attese brevi. L'ideale è 1-10 secondi. Qualsiasi valore oltre
un minuto dovrebbe farti riconsiderare se un Wait è lo strumento giusto.
-
Secondi dinamici. Se il ritardo varia per elemento o condizione, memorizzalo in
una variabile con un nodo Set Variable prima, poi referenzialo
nel campo Seconds:
{{ delay_step.output.delay_seconds }}.
-
Le attese sopravvivono ai riavvii dei worker. Se il queue worker si riavvia
mentre un Wait è attivo, il job verrà ri-accodato. L'attesa ripartirà da zero, il che
potrebbe risultare in una pausa più lunga del previsto. Progetta di conseguenza.
Nodi Correlati
- Loop — itera sugli elementi; posiziona un Wait all'interno per distribuire le iterazioni nel tempo.