Rollback in caso di errore e risoluzione dei conflitti

Eseguire il rollback di un'aggiunta (rimuovendo l'elemento) o di un'eliminazione (ripristinando l'elemento) è semplice. Il rollback di un aggiornamento è più complesso: è necessario ripristinare il valore precedente esatto. Se l'elemento è stato aggiornato più volte in modo ottimistico, è necessario tenere traccia separatamente di ogni valore precedente, non solo dello stato originale sul server.

Consideri questo scenario: il server ha un elemento con valore Z. Lei lo aggiorna ottimisticamente a X. Mentre la richiesta è in corso, un altro utente aggiorna lo stesso elemento a Y sul server. La richiesta arriva e il server la rifiuta (conflitto). Il target del rollback è Z, ma lo stato corrente del server è Y. Ripristinare Z sovrascriverebbe erroneamente Y.

La strategia di rollback più sicura per gli aggiornamenti consiste nell'eseguire il refetch dell'elemento dal server in caso di qualsiasi errore di mutazione, invece di ripristinare uno snapshot acquisito localmente. In questo modo viene garantito che sia visualizzato lo stato autorevole del server, indipendentemente da eventuali modifiche concomitanti apportate da altri utenti. Il refetch è più lento, ma è sempre corretto.

Un'API ben progettata restituisce HTTP 409 Conflict quando un aggiornamento ottimistico non riesce a causa di una modifica concomitante. Il corpo della risposta include in genere lo stato corrente del server. Il gestore degli errori dovrebbe rilevare il codice 409, usare il corpo della risposta per aggiornare lo stato locale con il valore corrente del server e notificare all'utente che le sue modifiche non sono state salvate.

Una mutazione idempotente produce lo stesso risultato quando viene applicata più volte. Progettare mutazioni idempotenti (usando PUT invece di POST, includendo lo stato completo della risorsa e usando chiavi di idempotenza) rende sicuro ritentare in caso di errore, senza il rischio di applicare la modifica due volte. Questo semplifica notevolmente la logica di rollback.

I doppi clic sul pulsante di invio possono attivare due mutazioni identiche. Lo prevenga con un flag isSubmitting: lo imposti su true all'avvio della mutazione e lo reimposti al completamento, sia in caso di successo sia di errore. Disabiliti l'elemento trigger quando isSubmitting è true. In questo modo elimina le mutazioni duplicate a livello di interfaccia utente.

Per la deduplicazione lato server, includa un header Idempotency-Key univoco in ogni richiesta di mutazione. Lo generi con crypto.randomUUID() quando l'utente avvia l'azione. Il server rileva le chiavi duplicate e restituisce la stessa risposta della richiesta originale senza applicare nuovamente l'operazione.

Durante una mutazione in corso, può mostrare un indicatore discreto che segnali che lo stato ottimistico non è confermato: un piccolo punto pulsante, il testo "Salvataggio..." o un'opacità ridotta sull'elemento. Questo comunica l'incertezza senza bloccare l'interazione. Rimuova l'indicatore in caso di successo oppure esegua il rollback in caso di errore.

Gli errori imprevisti nella logica di rollback (ad esempio, l'accesso alle proprietà di undefined durante il ripristino dello stato) possono causare il crash del componente. Racchiuda i componenti che usano molte mutazioni in un error boundary, così che gli errori catastrofici durante il rollback mostrino un'interfaccia utente di errore appropriata invece di una schermata vuota. Registri questi errori per il debugging.

Una strategia affidabile per rilevare i conflitti consiste nell'includere un numero di versione o un ETag in ogni mutazione. Il server confronta la versione inviata dal client con quella corrente. Se differiscono (si è verificato un altro aggiornamento), restituisce 409. Si tratta del controllo ottimistico della concorrenza: si presume che non ci siano conflitti, ma li si rileva quando si verificano.

La logica di rollback spesso non viene testata perché è difficile simulare i guasti di rete. Usi strumenti come Mock Service Worker (MSW) per restituire risposte di errore nei test. Scriva test espliciti per: gestione del 409 Conflict, rollback dopo il timeout di rete, deduplicazione dei doppi clic e coerenza dello stato dopo un errore. È in questi casi limite che si annidano i bug.

Quale codice di stato HTTP restituisce un'API ben progettata quando un aggiornamento ottimistico non riesce a causa di una modifica concomitante apportata da un altro utente?

Il rollback degli aggiornamenti è più complesso di quello delle aggiunte/eliminazioni: in caso di errore esegua sempre il refetch per evitare problemi dovuti a snapshot obsoleti. HTTP 409 Conflict segnala i fallimenti del controllo ottimistico della concorrenza; usi il corpo della risposta per ripristinare lo stato corrente del server. Progetti mutazioni idempotenti per consentire retry sicuri. Prevenga i doppi invii con isSubmitting e con chiavi di idempotenza lato server. Testi esplicitamente i percorsi di rollback usando MSW per simulare gli errori.