Errore 409 Conflict: API, salvataggi e risorse

Errore 409 Conflict: API, salvataggi e risorse: L’errore 409 Conflict indica che la richiesta è valida ma entra in conflitto con lo stato attuale della risorsa.

Errore 409 Conflict: API, salvataggi e risorse

Questa guida approfondisce errore 409 Conflict con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

Ripetere la stessa richiesta senza cambiare dati o stato tende a produrre ancora il conflitto. Il corpo della risposta dovrebbe spiegare quale vincolo è stato violato.

In WordPress il codice può provenire da plugin, REST API, servizi di sicurezza, e-commerce o integrazioni esterne, non necessariamente dal core.

Come riconoscere il problema

• Una API rifiuta la creazione di un elemento esistente.
• Due utenti salvano la stessa risorsa.
• Un webhook viene elaborato due volte.
• Un file o record risulta bloccato.
• Il client possiede una versione precedente dei dati.

Cause più frequenti

1. Risorsa duplicata

Slug, email, identificativo o chiave unica esistono già. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Aggiornamento concorrente

Due processi modificano lo stesso oggetto.

3. Versione non aggiornata

ETag, revision o timestamp non corrispondono.

4. Lock applicativo

Una importazione o modifica mantiene la risorsa occupata.

5. Webhook duplicato

Il provider ripete una notifica già gestita.

6. Cache o replica

Il client opera su uno stato precedente.

Diagnosi passo per passo

Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

1. Leggi il corpo della risposta. Cerca codice applicativo, campo e identificativo.
2. Controlla il metodo. POST, PUT e PATCH hanno semantiche differenti.
3. Verifica duplicati. Cerca l’oggetto tramite ID, slug o chiave.
4. Controlla ETag e versioni. Confronta If-Match, revisioni e timestamp.
5. Analizza richieste simultanee. Usa log, request ID e orari.
6. Controlla code e webhook. Verifica idempotency key e tentativi.
7. Svuota soltanto cache pertinenti. Rileggi lo stato reale prima di reinviare.

Procedura di risoluzione

Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

1. Aggiorna lo stato locale. Recupera la versione più recente della risorsa.
2. Usa un identificativo idempotente. Evita duplicati nei retry.
3. Risolvi il duplicato. Aggiorna l’oggetto esistente o usa una chiave diversa.
4. Gestisci il lock. Attendi la fine del processo o rimuovi lock orfani con procedura documentata.
5. Serializza le modifiche. Evita aggiornamenti concorrenti sullo stesso record.
6. Correggi webhook e code. Registra gli eventi già elaborati.
7. Riprova soltanto dopo la modifica. Un retry identico non risolve un conflitto permanente.

Guide Xlogic correlate

• Errore 400 Bad Request: cause e soluzioni
• Errore 414 URI Too Long: cause e soluzioni
• WordPress cURL error 6: Could not resolve host