L’errore 409 Conflict indica che la richiesta è valida ma entra in conflitto con lo stato attuale della risorsa. È comune in API, sincronizzazioni, creazione di oggetti duplicati, aggiornamenti concorrenti e sistemi che usano lock o versioni.
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. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Versione non aggiornata
ETag, revision o timestamp non corrispondono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Lock applicativo
Una importazione o modifica mantiene la risorsa occupata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Webhook duplicato
Il provider ripete una notifica già gestita. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Cache o replica
Il client opera su uno stato precedente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- La risorsa è unica.
- Gli aggiornamenti concorrenti sono gestiti.
- I webhook non creano duplicati.
- Il client usa la versione corrente.
- I retry sono idempotenti.
Prevenzione
- Usa chiavi idempotenti.
- Gestisci revisioni.
- Registra request ID.
- Evita processi sovrapposti.
- Documenta i lock.
Errori da evitare
- Non ripetere in loop la stessa richiesta.
- Non cancellare risorse per aggirare il conflitto.
- Non ignorare ETag e revisioni.
- Non svuotare tutto il database.
- Non condividere token nei log.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- endpoint e metodo
- codice e corpo risposta
- request ID
- orario
- identificativo della risorsa
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su errore 409 Conflict
Un 409 è un errore del server?
È un errore client 4xx legato a un conflitto con lo stato della risorsa.
Ritentare risolve?
Solo se lo stato cambia; un retry identico normalmente fallisce di nuovo.
Che cos’è una idempotency key?
Un identificativo che permette al server di riconoscere e non duplicare la stessa operazione.
Può dipendere dalla cache?
Sì, se il client opera su dati non aggiornati.
WordPress usa sempre il 409?
No. Il codice dipende dall’API o dal plugin che gestisce l’operazione.