Descrizione
Operatore di pausa event-driven enterprise che sospende l'esecuzione del workflow fino all'arrivo di un segnale esterno via HTTP — il pattern signal-and-wait classico di Temporal/Cadence Workflows e workflow orchestration enterprise, fondamento di tutti i processi long-running con interazione umana o coordinamento asincrono con sistemi esterni dove il tempo di attesa è ore-giorni-settimane (non secondi come logic_delay). Implementazione resilient: il run state completo (variables, step history, expression context) viene persistito nel checkpoint del SQLite runtime tenant in stato `paused_waiting_signal`, il workflow continua a contare nelle quote dei workflow attivi ma non consuma CPU/RAM mentre attende. Il signal arriva via POST `<tenant>.app.automazionezeli.com/signals/<signal_name>` con payload JSON opzionale — il portal scheduler intercetta, verifica permessi (signal_token segreto del workflow se signalRequiresAuth) e firma il resume del workflow da dove era stato sospeso. Sopravvive a TUTTO: restart container per deploy, crash del runtime, migrazione tra host fisici, pausa idle del container con wake-on-signal automatico, upgrade major version del runtime image. La pausa può durare letteralmente settimane senza degradation perché lo state vive in disco persistente, non in memoria volatile. Cap di sicurezza: timeoutMs configurabile (default 30 giorni, max 90gg) dopo il quale il workflow riprende con status `signal_timeout` e branch fallback eventualmente collegato. Match opzionale su payload via expression: invece di accettare CUALQUIER signal con name matching, è possibile filtrare ulteriormente con un'expression JavaScript-like (es. "$.payload.userId === currentUser && $.payload.action === 'approve'") che decide se questo signal è quello "giusto" per questo specifico run sospeso — pattern critico in scenari multi-run sospesi simultaneamente sullo stesso signal name dove serve discriminare. Output al resume: { signal_payload (intera JSON del POST body del signal), receivedAt (ISO timestamp), pausedDuration (ms tra pause e resume per metrics SLA) }. Use case: workflow approvazione fattura sopra una certa soglia (€10k+) che attende click del manager su pulsante "Approve" o "Reject" nell'inbox email (il button è un link al endpoint signal con UUID firmato embedded), pausa media 24-48h business hours; onboarding multi-step di un nuovo cliente B2B con conferma email (envia email link → user click link → signal received → workflow continua con setup automatic workspace + access provisioning), pausa media 1-3 giorni; processo legale con SLA giorni-settimane di attesa controfirme contratto da multiple parti via DocuSign webhook signal; pipeline ETL che attende batch downstream completed da sistema legacy mainframe che invia signal HTTP al termine; human-in-the-loop ML review dove il modello AI è incerto (confidence < soglia) e l'operatore deve validare prima della propagazione downstream alla produzione.