Cómo tratar una solicitud cuya clave de idempotencia ha caducado

Distingue caducidad técnica e historial de negocio

Distingue la retención de la clave en el proveedor, tu propio registro de resultados y la validez comercial de la solicitud. Pueden vencer en momentos distintos. Stripe documenta que, en API v1, reutilizar una clave cuya entrada se ha eliminado genera una nueva petición. Ese comportamiento no es universal: confirma versión, endpoint y política del proveedor que utilizas antes de programar la recuperación.

Recupera solicitud, parámetros, cuenta y último intento. Busca el objeto creado mediante su referencia de negocio o el identificador destino que guardaste. Si existe, enlázalo y reanuda únicamente lo que falta. Si no aparece, comprueba si la consulta incluye registros archivados, anulados y todas las páginas. Una búsqueda incompleta puede hacer pasar una creación antigua por una operación nunca ejecutada.

No renueves automáticamente la intención

Si confirmas que no se ejecutó y el negocio todavía la autoriza, prepara una nueva ejecución con identidad relacionada con el historial. Si cambió precio, disponibilidad o destinatario, pide revisar esos datos antes. Si el resultado sigue ambiguo, deriva el caso con las pruebas consultadas. En un ejemplo hipotético, un pedido de la semana pasada puede haberse servido por otro canal: recuperar la integración no autoriza volver a crearlo hoy.

Ajusta la conservación a la recuperación real

Registra el plazo conocido de protección y avisa antes de que pendientes importantes lo superen. Conserva referencias de negocio durante la ventana necesaria para reconciliar, con una política de datos aprobada. Prueba una entrega tardía cuando el proveedor ya no conserva la clave y comprueba que no activa una nueva creación sin revisión. Añade un registro archivado para verificar que la búsqueda lo encuentra. El objetivo es poder justificar la decisión aunque la garantía técnica original haya desaparecido.

Fuentes y documentación

• Stripe: solicitudes idempotentes — El contrato cambia entre API v1 y v2; revisa conservación de claves, parámetros y resultados.
• Azure Architecture Center: Retry — Distingue fallos transitorios, límites de intentos e impacto de políticas anidadas.