The phone retried a call the server was still processing. The second request ran the slow step again.

That was the bug.
A retry treated as a new job.

The user was waiting. The network cut the wait short. The client retried, and it was right to. On the server the two calls shared an intention and nothing else. Each one believed it was the first.

The effect was duplicated. When the second call met the first halfway through, the user saw an error and the system was left half-done.

I tried this first: store the key and, if a result already existed, return it.
That covers the easy case.
The first call has already finished.
The real case was the other one.
The first call was still alive.
There was no result to return yet.
With only that rule, the second call started the work again.

Leaving the key locked forever failed too.
If the process dies halfway, the "in progress" mark stays and the action is stuck.
A lock that never expires is worse than a duplicate.

The client chooses the key. The same action carries the same key.

If the first call is still in progress, the second one does not work. It responds 409, with `retryable` and a `retry_after`. The client waits and asks again. The downstream service is called once.

If the first call already finished, the retry returns that same result. One attempt. One effect.

If the process dies without marking success or failure, the mark expires. After that, the same key can be processed for real. If the downstream service fails, the key is released immediately.

The first response may never reach the phone. The second one does not have to be a 200 with a new effect. A 409, at that moment, is the right response.

The phone retried a call the server was still processing. The second request must not do the work again.

The 409 is the right response

El celular reintentó una llamada que el servidor todavía estaba procesando. La segunda entró igual y volvió a ejecutar el paso lento.

Ese fue el error.
Un reintento tratado como un trabajo nuevo.

El usuario esperaba. La red cortó la espera. El cliente, con razón, reintentó. En el servidor las dos llamadas compartían la intención y nada más. Cada una creía que era la primera.

El efecto quedaba duplicado. Cuando la segunda chocaba con la primera a mitad de camino, el usuario veía un error y el sistema quedaba a medias.

Lo intenté así: guardar la llave y, si ya había resultado, devolverlo.
Eso cubre el caso fácil.
La primera llamada ya terminó.
El caso real era el otro.
La primera seguía viva.
Todavía no había resultado que repetir.
La segunda arrancaba el trabajo otra vez.

Dejar la llave bloqueada para siempre tampoco.
Si el proceso muere a la mitad, la marca de "en curso" se queda y la acción queda cerrada.
Un lock eterno es peor que un duplicado.

La llave la elige el cliente. La misma acción trae la misma llave.

Si la primera sigue en curso, la segunda no trabaja. Responde 409, con `retryable` y un `retry_after`. El cliente espera y pregunta. El servicio de atrás se llama una vez.

Si la primera ya cerró, el reintento devuelve ese mismo resultado. Un intento. Un efecto.

Si el proceso muere sin marcar éxito ni fallo, la marca vence. Pasado el plazo, la misma llave se puede procesar de verdad. Si el servicio de atrás falla, la llave se suelta en ese momento.

La primera respuesta puede no llegar al celular. La segunda no tiene que ser un 200 con un efecto nuevo. Un 409, en ese momento, es la respuesta correcta.

El celular reintentó una llamada que seguía en curso. La segunda no puede hacer el trabajo otra vez.

Notas