Esecuzioni di cui puoi fidarti

Nessuno nota un'automazione finché non invia qualcosa due volte

Poi lo notano tutti. I quattro meccanismi di questa pagina esistono perché i guasti di questo tipo di software sono sempre gli stessi quattro guasti, e tutti sono evitabili per design anziché per attenzione.

Simula prima di pubblicare

Fai passare un record reale attraverso un workflow spento e leggi esattamente cosa sarebbe successo: il percorso seguito, ogni valore a ogni passaggio, il testo di ogni messaggio e la richiesta che sarebbe stata inviata a ogni sistema esterno.

Nulla esce fuori. Nessuna e-mail inviata, nessuna fattura emessa, nessun addebito tentato, nessuna riga scritta. Le chiamate esterne vengono registrate come intenzioni, con il payload che sarebbe stato inviato, così puoi vedere se il mapping è giusto prima che diventi un problema di qualcuno.

Le simulazioni sono il modo di rispondere alla domanda che impedisce alle persone di attivare un'automazione: cosa farà davvero?

Simulazione · ordine 88 214Nulla inviato

1Valida indirizzoTrovato. Avrebbe scritto 6 campi.
?CondizioneOrdine oltre 1 000 zł? No — 289,00 zł. Percorso breve seguito.
3FatturaAvrebbe fatto una POST al sistema di fatturazione. Payload mostrato per intero.
!Intercettato quiAliquota IVA mappata dal campo sbagliato. Trovata in una simulazione anziché nella casella di un commercialista.

Inviato: nullaAddebitato: nulla

Un'esecuzione percorre la versione su cui è entrata

Pubblicare una modifica a un workflow non tocca le esecuzioni già in corso. Ogni esecuzione è ancorata alla versione su cui è partita e la completa, per quanto tempo ci voglia e per quanto tu riscriva nel frattempo.

Così puoi ristrutturare un workflow mentre diecimila persone sono a metà strada, e ognuna di loro completa il flusso che le era stato promesso. L'alternativa — il design in cui l'intero percorso a valle viene materializzato all'ingresso — è il motivo per cui modificare un'automazione attiva sembra pericoloso nella maggior parte degli strumenti. Qui è una cosa normale.

Le nuove esecuzioni prendono la nuova versione dal momento in cui pubblichi. La versione su cui si trova un'esecuzione è scritta sull'esecuzione stessa, quindi una domanda sul comportamento di marzo ha una risposta a settembre.

Modifica in direttav4 → v5

1Prima2 918 esecuzioni in corso, tutte su v4. Alcune in un'attesa di due giorni.
2Pubblica v511:40Due passaggi riordinati, un messaggio riscritto.
3DopoQuei 2 918 finiscono la v4. Tutto ciò che parte dalle 11:40 esegue la v5.
§Nessunoha ricevuto metà di un workflow e metà di un altro.

Versione registrata su ogni esecuzioneVecchie versioni conservate

Retry che non possono inviare due volte

Un passaggio è una funzione pura dei suoi input, e i suoi effetti vengono confermati insieme all'avanzamento dell'esecuzione al passaggio successivo. Non esiste una finestra in cui il messaggio è già partito ma l'esecuzione non lo sa.

È tutto qui il trucco, ed è una proprietà strutturale anziché una promessa. Un worker ucciso a metà passaggio — un deploy, un crash, una macchina che sparisce — lascia l'esecuzione esattamente dov'era. Un altro worker la riprende e riesegue il passaggio. Poiché l'effetto e l'avanzamento vengono confermati come uno, o sono accaduti entrambi o nessuno dei due.

Le chiamate in uscita verso sistemi che supportano chiavi di idempotenza ne portano una, derivata dall'esecuzione e dal passaggio, così anche l'altra parte può riconoscere la ripetizione.

Worker ucciso a metà invioRecuperato

1Inizio del passaggio 509:14:06Invia l'avviso di spedizione.
✕Il worker muore09:14:07Deploy. Nulla era stato salvato.
2Ritirato09:14:31Un altro worker trova l'esecuzione ancora al passaggio 5.
✓Inviato una volta09:14:32Il cliente ha ricevuto una sola e-mail, non due.

Gli effetti vengono salvati insieme all'avanzamentoChiave di idempotenza per esecuzione e passaggio

Un log scritto per essere letto da una persona

Ogni esecuzione, ogni passaggio, il ramo seguito e il valore che lo ha deciso. Tempi per passaggio. Richiesta e risposta di ogni chiamata esterna, con le credenziali oscurate. La versione su cui girava l'esecuzione. Dove un'esecuzione è in attesa e fino a quando.

Quando qualcuno chiede che fine ha fatto l'ordine piazzato il quattordici, c'è una risposta, e trovarla richiede un minuto invece che un pomeriggio di incrocio dei log di tre sistemi.

Le esecuzioni fallite si raccolgono in un unico posto con il motivo raggruppato, così «quarantun fallimento durante la notte» si risolve in «un fornitore ha restituito 503 per nove minuti» invece di quarantuna indagini separate.

Durante la notte, raggruppati41 fallimenti

1Una sola causaL'API del fornitore ha restituito 503 tra le 02:41 e le 02:50.
2Che cosa è successoTutti i 41 sono stati ritentati; 39 sono riusciti al secondo tentativo.
3Rimasti in sospesoDue si sono fermati e aspettano una persona. Entrambi sono elencati con la riga che ha fallito.
§Non quarantunoindagini. Una sola, e una decisione su due record.

Credenziali oscurateVersione registrata

Che cosa non dichiariamo

Non pubblichiamo una cifra di uptime su una pagina di marketing, perché un numero senza una finestra di misurazione e una definizione di «attivo» è decorazione. Se ti serve a livello contrattuale, chiedi e parleremo di che cosa possiamo davvero impegnarci a garantire.

Non possiamo nemmeno rendere affidabile l'API di qualcun altro. Se un provider è giù, un flusso che dipende da lui aspetta, ritenta e alla fine si ferma con un motivo chiaro. Quello che possiamo promettere è che il fallimento sia visibile, che non corrompa nulla e che riprendere non invii il messaggio una seconda volta.

Sulle attese: un'esecuzione in attesa da due giorni è un wake_at sull'esecuzione, non un job fermo in una coda. Per questo un flusso può tenere centomila esecuzioni in un'attesa di tre settimane senza che nulla costi nulla, e per questo il numero di esecuzioni attualmente in attesa non è qualcosa a cui devi pensare.