Errore 409 Conflict: API, salvataggi e risorse

In breve: 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

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

Procedura di risoluzione

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

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