La solicitud de cambio se quedó sin respuesta.
¿Qué justificaría otro intento?

Pensemos en un flujo de fabricación propuesto en el que un asistente cambia el estado de revisión documental de un proveedor. Es un supuesto para la evaluación, no una implantación observada. El patrón Retry de Microsoft describe la ambigüedad principal: un servicio puede procesar correctamente una solicitud sin conseguir devolver la respuesta. Por tanto, un tiempo de espera agotado no demuestra ni fracaso ni éxito. Nuestra propuesta de ficha de decisión empieza por el destino y la operación originales, la versión de la interfaz o configuración pertinente si se conoce, el contenido enviado, los identificadores, la hora de envío y lo observado realmente. Conserve referencias autorizadas a las evidencias en lugar de copiar innecesariamente registros confidenciales. Separe la solicitud original de cualquier corrección posterior; de lo contrario, quien revise el caso no podrá saber si otro intento corresponde al mismo trabajo.

El patrón Idempotent Consumer de Microsoft distingue una clave estable para una operación lógica de un identificador de correlación que vincula mensajes relacionados. Este último puede conectar una solicitud con sus respuestas sin identificar un único cambio a efectos de tratar duplicados. Del mismo modo, el identificador de un proveedor no explica por sí solo qué cambio se pretende repetir. Pregunte al responsable técnico qué identificador reconoce realmente el servicio receptor, dónde se aplica la protección y qué promete la documentación. Calificar una solicitud de idempotente describe sus efectos al repetirse dentro de un alcance definido. No demuestra una ejecución de extremo a extremo exactamente una vez, la corrección del resultado de negocio ni una regla universal basada en el método de la solicitud.

El ejemplo del patrón Idempotent Consumer utiliza mensajes de Service Bus y registros de pedidos en Azure Cosmos DB. Cuando ya existe un identificador, el consumidor compara un hash almacenado de la solicitud, una representación compacta del contenido, o campos de negocio inmutables. Si coinciden, trata el mensaje como duplicado. Si el contenido es distinto bajo el mismo identificador, lo deriva para su revisión en vez de descartarlo sin más. Es un ejemplo específico de mensajería y base de datos, no una respuesta prometida por una API de proveedores. Para un cambio de proveedor propuesto, pregunte cómo distingue la interfaz real un reenvío sin cambios de una solicitud corregida. Ni conservar el identificador antiguo ni crear uno nuevo resuelve por sí solo la incertidumbre original. La conservación de registros debe figurar en la misma ficha. Microsoft advierte de que eliminarlos demasiado pronto permite duplicados tardíos, incluidos trabajos que los operadores vuelven a enviar después del periodo habitual de reentrega. Pida el plazo documentado y compruebe si aún cubre esta operación. Estas fuentes no fijan una duración universal para las claves; que un identificador aparezca en un registro no prueba que el receptor siga reconociéndolo.

El patrón Asynchronous Request-Reply de Microsoft separa la aceptación, el estado y el resultado final. Propone devolver el recurso de estado existente cuando se recibe una clave de idempotencia duplicada, en vez de añadir otro trabajo. Pregunte si la interfaz real sigue ese diseño y cómo puede un solicitante autorizado recuperar la operación original cuando se pierde la respuesta de aceptación. No dé por hecho que cualquier endpoint permite buscar por clave. Interprete el estado según la interfaz documentada. La guía describe implementaciones que devuelven 404 antes de que exista el recurso de destino, lo que puede confundirse con un identificador no válido. Por separado, recomienda una política de conservación de estados y resultados. Pregunte qué implica su caducidad; no suponga que genera un código concreto ni que demuestra que la operación no se ejecutó. El patrón del consumidor también contempla acciones externas que no pueden formar parte de una transacción de la base de datos local. Una marca «en curso» puede representar trabajo parcial u otro consumidor que sigue procesándolo. Microsoft pide esclarecer los registros sin resolver o derivarlos para intervención. La protección local frente a duplicados no protege automáticamente a los servicios posteriores.

Proponemos un único expediente de traspaso que reúna la identidad y el contenido de la operación, el alcance y la conservación documentados del tratamiento de duplicados, las evidencias de estado admitidas, el trabajo externo sin resolver y el nombre del responsable de decidir. Los responsables técnicos explican qué permiten concluir las evidencias; el responsable de negocio autoriza la siguiente acción. El permiso para realizar el cambio original no demuestra su resultado. En una evaluación autorizada, pregunte cómo se abordarían el contenido coincidente, el contenido modificado bajo un mismo identificador, la falta de estado y las evidencias cuyo plazo de conservación haya vencido. Son casos de revisión que proponemos, no procedimientos obligatorios del proveedor ni pruebas realizadas aquí. De ellos no se deduce un número de reintentos ni un intervalo de espera. Si las evidencias admitidas demuestran que la operación terminó, documéntelo sin volver a modificar nada solo para confirmarlo. Si las condiciones documentadas aplicables permiten otro intento, recoja sus requisitos antes de autorizarlo. Si no existe una vía admitida para esclarecer el resultado o esta no es concluyente, el responsable debe autorizar expresamente mantener la operación en espera y asignar el seguimiento. La falta de respuesta no concede permiso para repetir el cambio.