Rollback ante errores y resolución de conflictos

Revertir una adición optimista (eliminar el elemento) o una eliminación (restaurar el elemento) es sencillo. Revertir una actualización es más complejo: debe restaurar el valor anterior exacto. Si el elemento se actualizó varias veces de forma optimista, debe realizar un seguimiento de cada valor anterior por separado, no solo del estado original del servidor.

Considere este escenario: el servidor tiene un elemento con el valor Z. Usted lo actualiza de forma optimista a X. Mientras la solicitud está en curso, otro usuario actualiza el mismo elemento a Y en el servidor. Su solicitud llega y el servidor la rechaza (conflicto). El objetivo de la reversión es Z, pero el estado actual del servidor es Y. Restaurar Z sobrescribiría Y de forma incorrecta.

La estrategia de reversión más segura para las actualizaciones consiste en volver a solicitar el elemento al servidor ante cualquier error de mutación, en lugar de restaurar una instantánea capturada localmente. Esto garantiza que se muestre el estado autoritativo del servidor, independientemente de los cambios simultáneos que hayan realizado otros usuarios. Volver a solicitar los datos es más lento, pero siempre es correcto.

Una API bien diseñada devuelve HTTP 409 Conflict cuando una actualización optimista falla debido a una modificación simultánea. El cuerpo de la respuesta suele incluir el estado actual del servidor. Su controlador de errores debe detectar el estado 409, usar el cuerpo de la respuesta para actualizar el estado local con el valor actual del servidor y notificar al usuario que sus cambios no se guardaron.

Una mutación idempotente produce el mismo resultado cuando se aplica varias veces. Diseñar mutaciones idempotentes (usando PUT en lugar de POST, incluyendo el estado completo del recurso y usando claves de idempotencia) permite reintentar de forma segura cuando se produce un error, sin riesgo de aplicar el cambio dos veces. Esto simplifica considerablemente la lógica de reversión.

Los dobles clics en un botón de envío pueden ejecutar dos mutaciones idénticas. Evítelo con un indicador isSubmitting: establézcalo en true cuando comience la mutación y restablézcalo cuando termine, tanto si tiene éxito como si falla. Deshabilite el elemento disparador cuando isSubmitting sea true. Esto elimina las mutaciones duplicadas en el nivel de la interfaz de usuario.

Para realizar la desduplicación en el servidor, incluya un encabezado Idempotency-Key único en cada solicitud de mutación. Genérelo con crypto.randomUUID() cuando el usuario inicie la acción. El servidor detecta las claves duplicadas y devuelve la misma respuesta que la solicitud original sin volver a aplicar la operación.

Mientras una mutación está en curso, puede mostrar un indicador sutil de que el estado optimista aún no está confirmado: un pequeño punto pulsante, el texto "Guardando..." o una opacidad reducida en el elemento. Esto comunica la incertidumbre sin bloquear la interacción. Quite el indicador cuando la operación tenga éxito o revierta los cambios si falla.

Los errores inesperados en la lógica de reversión (por ejemplo, acceder a propiedades de undefined durante la restauración del estado) pueden bloquear el componente. Envuelva los componentes que realizan muchas mutaciones en un límite de error para que los fallos catastróficos de reversión muestren una interfaz de error adecuada en lugar de una pantalla en blanco. Registre estos errores para depurarlos.

Una estrategia fiable para detectar conflictos consiste en incluir un número de versión o un ETag en cada mutación. El servidor compara la versión enviada por el cliente con su versión actual. Si difieren (se produjo otra actualización), devuelve 409. Esto es control de concurrencia optimista: se supone que no hay conflictos, pero se detectan cuando ocurren.

La lógica de reversión a menudo no se prueba porque los fallos de red son difíciles de simular. Use herramientas como Mock Service Worker (MSW) para devolver respuestas de error en las pruebas. Escriba pruebas explícitas para: gestión del conflicto 409, reversión tras un tiempo de espera de red, desduplicación de dobles clics y coherencia del estado después de un fallo. Los errores suelen ocultarse en estos casos límite.

¿Qué código de estado HTTP devuelve una API bien diseñada cuando una actualización optimista falla debido a una modificación simultánea realizada por otro usuario?

La reversión de una actualización es más compleja que la de una adición o eliminación: vuelva a solicitar siempre los datos cuando se produzca un error para evitar problemas con instantáneas obsoletas. HTTP 409 Conflict indica fallos de concurrencia optimista; use el cuerpo de la respuesta para restaurar el estado actual del servidor. Diseñe mutaciones idempotentes para permitir reintentos seguros. Evite ejecuciones duplicadas con isSubmitting y claves de idempotencia en el servidor. Pruebe explícitamente las rutas de reversión mediante MSW para simular errores.