Coda resiliente: un'interruzione dell'infrastruttura non uccide più l'attività

Fix di produzioneReinserimento in coda in caso di interruzione dell'infrastruttura, non-marcare-come-annullato-al-riavvio, due query che PostgreSQL rifiutava sempre, guard di classe per silent failures, e warmup di thread di email senza risposta pre-scritta.

Perché è una notizia di prodotto

I 15 specialisti di ADRI dipendono da OllamaTasker + Node balancer + FastAPI. Se un worker si riavvia alle 3:00, il commerciale non dovrebbe vedere “hai annullato l'attività”. Dovrebbe vedere un nuovo tentativo o un reinserimento in coda — e il silent-failure-hunter non dovrebbe mentire sull'interruzione.

• Le attività lunghe (OSINT, code, vision) sopravvivono ai blip
• Billing e tools_used si chiudono solo alla fine reale del turno
• Gli operatori vedono il motivo onesto dell'interruzione

Architettura delle code nel tuo on-prem

Cosa falla quando la coda non è resiliente

In un'architettura multi-agente (Laravel tasker + balancer Node + API Python), un riavvio di worker alle 3:00 non è “un bug raro”: è la quotidianità. Se l'attività viene marcata come annullata o sparisce, l'utente perde fiducia e il billing si desincronizza (turno aperto, tool addebitati a metà).

• Reinserimento in coda: l'unità di lavoro torna in coda con lo stesso id di sessione/workspace.
• Idempotenza: i tool di scrittura non duplicano gli effetti se il passo si ripete.
• Chiusura onesta: i token e tools_used si consolidano alla fine reale del turno.

Segnali operativi

Gli operatori devono vedere perché è stato ritentato (timeout LLM, OOM, deploy), non un “errore generico”. Questo è ciò che permette di distinguere un guasto del modello da un'interruzione dell'infrastruttura.

Domande frequenti

Correlato: agenti ADRI · architettura nella tua infrastruttura.

• Code
• Resilienza
• OllamaTasker
• SRE