I job in background falliscono in modi che le richieste web non conoscono: i worker si riavviano a metà task, i broker riconsegnano i messaggi e le API esterne vanno in timeout nel momento peggiore. L'affidabilità nasce dal progettare questi fallimenti in anticipo, non dallo sperare che non accadano.
Rendi ogni task idempotente
Un task eseguito due volte deve produrre lo stesso risultato di uno eseguito una volta. Il modo più economico è una chiave univoca salvata in Redis: prima di lavorare, controlla la chiave; a lavoro finito, impostala.
import redis
r = redis.Redis()
def run_once(job_id: str, fn):
if r.set(f"job:{job_id}", "done", nx=True, ex=86400):
fn() # solo la prima consegna viene eseguitaRetry con backoff, non con speranza
I retry di Celery devono essere espliciti: tentativi limitati, backoff esponenziale e jitter, così una flotta di worker non travolge un'API in difficoltà tutta nello stesso secondo.
@app.task(bind=True, autoretry_for=(TimeoutError,),
retry_backoff=True, retry_jitter=True, max_retries=5)
def sync_payment(self, charge_id: str):
...Tutto il resto va in dead-letter
Dopo l'ultimo retry, sposta il job in una dead-letter queue e lancia un alert. Un job fallito che puoi ispezionare è un fastidio; un job fallito che sparisce è un rimborso. Questo pattern è integrato nei nostri boilerplate proprio perché tutti lo riscoprono nel modo più duro.