Production fixesRequeueing on infra outage, not marking cancelled on restart, two queries that PostgreSQL always rejected, class guard for silent failures, and email thread warmup without pre-written reply.
Why this is product news
ADRI's 15 specialists depend on OllamaTasker + Node balancer + FastAPI. If a worker restarts at 3AM, the sales rep should not see “you cancelled the task”. They should see retry or requeueing — and the silent-failure-hunter should not lie about the outage.
- Long tasks (OSINT, code, vision) survive blips
- Billing and tools_used are only closed at the real end of the turn
- Operators see the honest reason for the outage
Queue architecture in your on-prem
What fails when the queue is not resilient
In a multi-agent architecture (Laravel tasker + Node balancer + Python API), a worker restart at 3:00 is not “a rare bug”: it is everyday life. If the task is marked cancelled or disappears, the user loses trust and billing becomes desynchronised (open turn, tools charged halfway).
- Requeueing: the unit of work returns to the queue with the same session/workspace id.
- Idempotency: write tools do not duplicate effects if the step is repeated.
- Honest closure: tokens and
tools_usedare consolidated at the real end of the turn.
Operational signals
Operators must see why it was retried (LLM timeout, OOM, deploy), not a “generic error”. That is what allows distinguishing a model failure from an infra outage.
Frequently asked questions
Does it only affect code/OSINT?
Any long turn (vision, browser, enrichment) benefits. Turns of 2–3 seconds are barely noticeable.
Can I use it on-premise?
Yes: the queue is part of the BionicAdri/ADRI stack, not a mandatory third-party SaaS.
What does the end user see?
Retry or “resuming…” — not a false cancellation message.
Related: ADRI agents · architecture in your infra.
- Queues
- Resilience
- OllamaTasker
- SRE