Marvin
09/23/2025, 2:05 PMMarvin
09/23/2025, 2:12 PMthreshold: 5
e within: 60
. Questo significa che l’automation scatterà solo dopo 5 eventi che corrispondono ai filtri entro 60 secondi. Dall’evento che hai incollato vedo un solo prefect.flow-run.Failed
, quindi il trigger non ha raggiunto la soglia.
- Se vuoi che parta al primo fallimento, imposta threshold: 1
.
2) match vs match_related
- Il campo prefect.state-message
appartiene alla risorsa primaria dell’evento (vedi nel tuo payload: è dentro resource
, non in related
). Quindi va messo in match
, non in match_related
. Con match_related
stai filtrando su risorse “collegate” (deployment, work-pool, ecc.), non sul flow-run stesso.
Inoltre:
- Il filtro prefect.resource.id: ["prefect.flow-run.*"]
non è necessario, dato che stai già usando expect: ["prefect.flow-run.Failed"]
, che limita il trigger ai soli eventi dei flow run in stato Failed. Può anche restringere inutilmente il matching. Ti consiglio di rimuoverlo per semplificare.
- Filtrare su prefect.state-message
è “fragile” perché il testo può cambiare. Se lo usi, assicurati che la stringa combaci esattamente (come nel tuo esempio).
Proposta di configurazione minima che dovrebbe partire al primo fallimento da git_clone:
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
after: []
expect:
- "prefect.flow-run.Failed"
posture: "Reactive"
threshold: 1
within: 60
Per l’azione:
- In Prefect Cloud 2.x l’azione tipica è “Run deployment” / “Create flow run” (spesso con opzione “infer deployment” dall’evento). Assicurati che l’azione che hai scelto avvii un nuovo flow run dal deployment correlato. Se l’azione nel tuo workspace si chiama “Resume deployment”, verifica che in realtà stia creando/rilanciando un flow run del deployment associato (se vuoi, condividi uno screenshot dell’azione e la ricontrolliamo insieme).
Suggerimenti pratici:
- Nella UI usa “Preview matches” (se disponibile) o prova ad abbassare threshold
a 1 e lanciare un fallimento di test per vedere se scatta.
- Valuta di non dipendere esclusivamente dalla state-message
e, se possibile, aggiungere altri filtri (es. limitare a uno specifico deployment usando match_related
con l’id del deployment) per evitare false partenze.
Riferimenti utili:
- Automations in Prefect Cloud 2.x
- Event triggers (match, match_related, threshold/within)
Se il tuo obiettivo è “ri-tentare automaticamente quando il git clone/pull fallisce”, questa Automation con threshold: 1
e azione “run deployment (infer from event)” è il modo giusto in Prefect 2.x, dato che il fallimento avviene prima di caricare il flow (quindi i retry del flow non si applicano).
Vuoi che ti proponga una versione che limiti il trigger solo a un determinato deployment e con un minimo “backoff” tra tentativi per evitare loop rapidi? Posso fornirti un esempio completo.MarcoM
09/23/2025, 2:37 PMMarvin
09/23/2025, 2:37 PMMarvin
09/23/2025, 2:37 PMMarcoM
09/23/2025, 2:38 PMMarvin
09/23/2025, 2:38 PMMarvin
09/23/2025, 2:38 PMMarvin
09/23/2025, 2:40 PMMarvin
09/23/2025, 2:42 PMgit_clone
, devi usare un’azione che CREI un nuovo flow run, non che modifichi lo stato della schedule. In UI questa azione è tipicamente “Run a deployment” (a volte chiamata “Create flow run”), con “infer deployment” dall’evento.
Cosa fare subito
- Modifica l’Automation sostituendo l’azione “resume-deployment” con “run-deployment” (o “create flow run”) e imposta “deployment: infer from event”.
- Se vuoi farla partire al primo fallimento, tieni threshold: 1
.
Esempio di trigger + azione che crea una nuova run
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 300
actions:
- type: run-deployment
deployment: infer
parameters: {} # opzionale: aggiungi parametri se servono
Note e suggerimenti
- “Infer deployment” funziona perché l’evento prefect.flow-run.Failed
include il deployment correlato nei related
. L’azione “run-deployment” userà quell’ID per creare una nuova run.
- Se devi ripassare gli stessi parametri della run fallita, confermami come li imposti (statici vs dinamici) e ti propongo il modo migliore; in alcuni casi conviene fissarli nell’azione, oppure leggere dal contesto evento se disponibile.
- Attenzione ai loop: se git_clone
continua a fallire, ogni run fallita innescherà un’altra run. Puoi mitigare con:
- threshold/within
per limitare la frequenza (es. max 3 tentativi in 10 min)
- una seconda automation che, dopo N fallimenti, disabilita la schedule o invia un alert invece di rilanciare.
Vuoi che ti prepari una versione “anti-loop” che faccia fino a 3 retry in 10 minuti e poi smetta di rilanciare, magari inviando una notifica?MarcoM
09/23/2025, 3:23 PMMarvin
09/23/2025, 3:23 PMMarvin
09/23/2025, 3:26 PMtype: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
match_related:
# limita al deployment "base"
prefect.resource.id:
- "prefect.deployment.<ID_DEL_BASE>"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 600
actions:
- type: run-deployment
deployment: "prefect.deployment.<ID_RETRY_1>"
parameters: {}
- Automation 2 — da retry-1 a retry-2
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
match_related:
prefect.resource.id:
- "prefect.deployment.<ID_RETRY_1>"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 600
actions:
- type: run-deployment
deployment: "prefect.deployment.<ID_RETRY_2>"
- Automation 3 — da retry-2 a retry-3
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
match_related:
prefect.resource.id:
- "prefect.deployment.<ID_RETRY_2>"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 600
actions:
- type: run-deployment
deployment: "prefect.deployment.<ID_RETRY_3>"
- Automation 4 — dopo retry-3, stop e avvisa
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
match_related:
prefect.resource.id:
- "prefect.deployment.<ID_RETRY_3>"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 600
actions:
- type: send-notification
# il tuo canale (Slack/Email/etc.)
recipient: "<il_tuo_canale>"
message: "Git clone failed 3 times in 10m for <flow/deployment>. Manual intervention required."
# opzionale: pausa la schedule del base per sicurezza
- type: pause-schedule
deployment: "prefect.deployment.<ID_DEL_BASE>"
Note importanti:
- Usa gli ID reali dei deployment (li trovi nell’evento nei related oppure dalla UI).
- L’azione è “run-deployment” (non “resume-deployment”).
- Questa catena garantisce fino a 3 retry senza loop, perché ogni Automation ascolta SOLO i fallimenti del suo deployment specifico.
Soluzione B (alternativa con tag; più delicata)
- È possibile farlo con 3 automations a “stadi” basati su tag (retry-1/2/3), ma dipende da come l’azione “Run deployment” imposta i tag sulla nuova run (se li sostituisce o li unisce ai tag del deployment). Per evitare ambiguità e loop, la soluzione con deployment separati è preferibile in 2.x.
Consigli extra per ridurre i fallimenti git:
- Se possibile, avvolgi il pull step git_clone
con un retry/backoff lato shell (es. step custom che tenta 3 volte con sleep esponenziale). Questo evita di dover ricorrere al rilancio completo del deployment per transitori di rete.
- Documentazione Automations: Automations in Prefect Cloud 2.xMarvin
09/23/2025, 3:26 PMMarcoM
09/23/2025, 3:29 PMMarvin
09/23/2025, 3:29 PMMarvin
09/23/2025, 3:30 PMthreshold: 1
, l’automazione scatta per ogni evento che matcha. In questo caso within
non aggrega nulla: puoi lasciarlo così, ridurlo a 0
, oppure ometterlo (se la UI lo consente). Mettere within: 0
rende esplicito che non vuoi alcuna finestra temporale.
Esempio minimale del trigger:
type: event
match:
prefect.state-message:
- "Flow could not be retrieved from deployment. StepExecutionError: Encountered error while running prefect.deployments.steps.git_clone"
expect:
- "prefect.flow-run.Failed"
posture: Reactive
threshold: 1
within: 0
Punti critici da verificare:
- Azione: usa “Run deployment” / “Create flow run” con “infer deployment from event” (non “Resume deployment”, che riattiva la schedule ma non crea una nuova run).
- Il match su prefect.state-message
è un match esatto; se il testo cambia anche di poco, non scatterà. Se dovesse capitare spesso, possiamo aggiungere filtri alternativi (es. limitare per deployment in match_related
) o rimuovere la dipendenza dal messaggio.
Nota sul loop:
- Così com’è, ogni fallimento in git_clone
rilancerà immediatamente il deployment e potresti avere molte run in coda se il problema persiste. Se in futuro vuoi introdurre un “paracadute”, puoi aggiungere una seconda automation che dopo N fallimenti in M minuti invii una notifica o metta in pausa la schedule.
Riferimenti:
- Automations in Prefect Cloud 2.x
Se vuoi, condividi uno screenshot dell’azione in UI e ti confermo che è impostata su “Run deployment (infer)”.