Reintentos, idempotencia y orden de eventos

Casi todos los emisores de webhooks prometen entregar cada aviso al menos una vez, no exactamente una vez. Si el receptor no responde con un código de éxito dentro del plazo, el emisor no sabe si el aviso se procesó o no, y lo vuelve a mandar. Desde su lado es la decisión correcta: perder un pago aprobado es peor que repetirlo.

La consecuencia es que los duplicados no son un fallo raro del proveedor, sino el comportamiento normal, y la defensa vive en el receptor. Un manejador es idempotente cuando procesar el mismo aviso una o diez veces deja el sistema igual. Se consigue con el identificador del evento: se registra con una restricción de unicidad antes de aplicar efectos, y si ya existe, se responde éxito sin volver a aplicarlos.

Abre el laboratorio. Lee manejador-avisos.js con el reloj en la mano: qué hace antes de responder y cuánto tarda, frente al plazo que espera el proveedor según el encargo. Después busca en entregas-proveedor.txt los eventos con más de un intento y confirma en registro-aplicacion.txt cuántas veces se aplicó cada uno.

Para el informe, el alcance se mide en pesos. Suma lo que se acreditó de más: por cada evento de reembolso, las acreditaciones que sobran respecto a la única que correspondía.

El orden es el segundo problema. El manejador copia en el pedido el estado que trae el aviso, sin preguntarse si es más nuevo que el que ya tiene. En la exportación del proveedor hay una columna que dice cuándo se creó cada evento, distinta de la hora en que se envió cada intento. Busca un pedido cuyos avisos llegaron en orden distinto al de su creación y mira en estado-pedidos.txt cómo quedó.

Hay tres causas encadenadas: el trabajo lento antes de responder provoca los reintentos, la falta de registro del identificador convierte cada reintento en dinero, y copiar el estado del aviso sin compararlo deja que uno viejo pise a uno nuevo.