La pregunta que un timeout no responde
Cuando una petición a una API de publicación da timeout, el cliente solo sabe que no llegó respuesta. No sabe si el post existe. MDN describe el estado Request Timeout en términos de la conexión: el servidor quiere cerrar una conexión sin uso. Es una afirmación sobre una conexión, no sobre un post.
Reintentar a ciegas puede producir un duplicado. No reintentar puede perder un post. Ambos errores son públicos.
Un estado explícito para «no lo sé»
Los tests registran un timeout del post tras el envío como unconfirmed. Un docstring de test dice que 409 y 408 no prueban que no se creó nada, exactamente igual que 5xx. Esas respuestas son ambiguas, y ambiguo no significa fallido.
Los fallos previos al post son distintos. Un timeout al subir la imagen se registra como failed, no como unconfirmed, y un comentario del test dice ‘uploading creates nothing public: retryable’. Una respuesta 400 definitiva se registra como failed, y la publicación normal puede reintentar.
Qué bloquea el estado unconfirmed
Un segundo clic en publicar sobre una fila unconfirmed responde already_attempted, y el proveedor simulado sigue teniendo un único post registrado.
Una fila también puede quedar a medias. Un docstring de test describe un proceso que murió en mitad del POST y dejó una fila publishing que no es reintentable ni reconciliable. El mismo test dice: After the sweep window it must become unconfirmed so the human recovery actions apply. El mensaje del commit dice: LinkedIn: 408/409 ambiguous, stale publishing swept to unconfirmed, audited manual confirm/allow-retry.
Un humano es la salida
Existen dos acciones de recuperación, y en los tests ambas exigen el permiso de publicación humano.
- confirm-published registra la URN del post, audita quién confirmó y no hace ninguna llamada al proveedor. También rechaza referencias en las que no puede confiar.
- allow-retry exige que la fila tenga cierta antigüedad y una frase de confirmación exacta. Un comentario de test afirma que permitir un reintento no publica. La publicación es un clic aparte.
Los tests muestran que las acciones de recuperación exigen el permiso de publicación humano.
La regla que me llevo
La idempotencia no es una política de reintentos. Es una máquina de estados con un estado explícito para «no lo sé», y un humano como única vía para forzar un reintento.
Si mantienes una integración de publicación, escribe tu estado «no lo sé» antes del primer timeout.
