HTTP 424 Failed Dependency

Cos'e HTTP 424 Failed Dependency

Il codice HTTP 424 Failed Dependency, definito dalla RFC 4918 (WebDAV), indica che l'azione richiesta non puo essere eseguita perché dipende da un'altra azione che e fallita. Nato in ambito WebDAV, oggi viene usato anche in API REST per operazioni transazionali o batch.

Scenario WebDAV classico

Un COPY ricorsivo di una cartella in WebDAV trasforma in singola operazione "copia ogni file della directory":

COPY /source/folder HTTP/1.1
Destination: /dest/folder
Depth: infinity

HTTP/1.1 207 Multi-Status

<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/source/folder/protected.txt</D:href>
    <D:status>HTTP/1.1 403 Forbidden</D:status>
  </D:response>
  <D:response>
    <D:href>/source/folder/</D:href>
    <D:status>HTTP/1.1 424 Failed Dependency</D:status>
  </D:response>
</D:multistatus>

L'errore 403 sul file protetto impedisce la copia completa della directory parent, che riceve 424 per dipendenza.

Quando si verifica 424

• PROPPATCH multi-property dove il fallimento su una proprietà blocca le altre.
• COPY/MOVE ricorsivi che dipendono dal successo su sotto-risorse.
• API REST batch dove le operazioni sono transazionali.
• Pipeline workflow dove uno step richiede output dello step precedente.

Esempio API REST moderna

Un'endpoint che crea un'utente E gli associa subscription:

POST /api/v2/onboarding HTTP/1.1
Content-Type: application/json

{
  "user": {"email": "duplicate@example.com"},
  "subscription": {"plan": "pro"}
}

HTTP/1.1 207 Multi-Status

{
  "operations": [
    {
      "step": "create_user",
      "status": 422,
      "error": "Email already exists"
    },
    {
      "step": "create_subscription",
      "status": 424,
      "error": "Failed dependency: create_user failed"
    }
  ]
}

424 vs 409 Conflict

• 409: il conflitto e con lo stato corrente della risorsa stessa.
• 424: il fallimento e dovuto a un'altra operazione (precedente o concorrente).

424 vs 412 Precondition Failed

• 412: una precondizione esplicita (If-Match, If-Unmodified-Since) non e soddisfatta.
• 424: una dipendenza interna del workflow ha fallito (no header espliciti coinvolti).

Implementazione server

def batch_operation(operations):
    results = []
    failed = False
    for op in operations:
        if failed:
            results.append({"status": 424, "error": "Previous step failed"})
            continue
        try:
            execute(op)
            results.append({"status": 200})
        except Exception as e:
            failed = True
            results.append({"status": 500, "error": str(e)})
    return 207, results

Modalita transazionale vs best-effort

Quando affronti operazioni batch, decidi la strategia:

• All-or-nothing (transazionale): se uno step fallisce, tutti gli altri sono 424 e si rolla back.
• Best-effort: gli step indipendenti procedono, solo i veri dipendenti diventano 424.

Documenta chiaramente quale modello adotta la tua API: hanno implicazioni profonde sull'idempotenza.

Rollback e idempotenza

In sistemi transazionali distribuiti, dopo un 424 il client puo:

1. Ricevere lo stato di tutte le operazioni.
2. Decidere se ritentare l'intera batch.
3. Compensare le operazioni eseguite (saga pattern).

Idempotency keys aiutano: client invia Idempotency-Key: xyz e il server riconosce retry di stessa batch.

424 in GraphQL

GraphQL non usa codici HTTP per errori di campo (sempre 200), ma il concetto di "failed dependency" emerge nelle resolver chain: un parent null fa skip di tutti i child. Il client riceve errors array con path e messaggi.

Gestione client

Quando ricevi un 424:

• Cerca nel multistatus o body quale operazione principale e fallita.
• Risolvi prima quella (es. fix dei dati, retry, rimozione conflitto).
• Ritentare solo le operazioni 424, non quelle 200.

Errori comuni

• Confondere 424 con 502/504: 424 e un fallimento logico, 502/504 sono problemi di rete/server.
• Usare 424 per qualsiasi errore in cascata: applicalo solo a dipendenze esplicite, altrimenti il client perde informazioni.
• Restituire solo 424 senza specificare l'operazione fallita originaria: rende impossibile il debug.

Logging e monitoring

I 424 ricorrenti su una stessa coppia di operazioni segnalano fragilita del workflow. Tracking metric:

• Tasso di 424 per endpoint batch.
• Quale operazione "root" causa il 424 più spesso.
• Latenza tra root failure e cascade.

Saga pattern e compensazione

In sistemi distribuiti, quando un'operazione composta fallisce parzialmente, il pattern Saga compensa le azioni già eseguite. Esempio: prenotazione viaggio (volo + hotel + auto). Se hotel fallisce, Saga compensa cancellando volo e auto. Il 424 e un segnale appropriato per indicare al client quale step ha causato la cascata.

Idempotency-Key

Header Idempotency-Key: uuid consente al client di ritentare batch in modo sicuro: se il server ha già processato quella key, ritorna il risultato cached invece di rieseguire. Combinato con 424, permette retry efficiente senza duplicazioni.

424 e workflow engines

Workflow engine come Temporal, Camunda gestiscono naturalmente dipendenze. Quando esposti via HTTP API, possono riportare 424 per step downstream che non vengono eseguiti perché upstream e fallito. Aiuta debugging e observability.

Differenza con 422 multipli

Un'API puo voler riportare molti errori di validazione in un solo 422 (campo errors[] con per-field detail). Il 424 invece e specifico per dipendenze: una validazione e fallita, e questo invalida operazioni che dipendevano dal successo. Concetti diversi, codici diversi.

Logging cascade failures

Quando si verificano 424 in cascata, log strutturato deve preservare la catena: quale e l'errore root, quali sono le conseguenze. Tracciamento distribuito (Jaeger, Tempo) aiuta a visualizzare la propagazione.

Best practice client gestione 424

Quando il client riceve 424, deve: (a) identificare il root failure dal body multistatus o dal payload JSON, (b) decidere strategia in base al tipo di errore (retry vs intervento utente vs rollback), (c) non assumere automaticamente che il retry risolvera (il root failure deve essere indirizzato prima). Logging chiaro client-side della cascade aiuta troubleshooting.

424 vs 500 in cascade

Distinzione importante: 424 indica "questo step non e stato eseguito perché dipendeva da altro fallito" (intenzionale, semantic). 500 invece e errore non gestito del server. Usa 424 quando la cascata e una decisione architetturale; 500 per crash non gestiti.

Implementazione con job queues

Job queue system come Sidekiq, Celery, BullMQ gestiscono naturalmente dipendenze tra job. Job downstream falliscono automaticamente se upstream fallisce. Esposizione via HTTP API puo emettere 424 quando il client interroga lo stato del downstream job che non e mai stato eseguito.

Logging strutturato

Per debugging effettivo di cascade failures, logging deve includere: correlation_id condiviso tra step, ordine di esecuzione, timestamp, codice esatto di ogni step. Tool come Elasticsearch + Kibana o Grafana Loki visualizzano timeline distribuiti.

Hai bisogno di aiuto?

Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.