Model-State Gating vs. Idempotency Keys for HTTP Write Retries

Preventing Duplicate Writes in Elm MVU

When implementing retry logic for HTTP POST requests in Elm 0.19+, ensuring that a single user action does not result in duplicate server-side records is a critical design constraint. Because the Elm runtime manages Cmd execution, multiple triggers of the same effect can lead to redundant writes if the network is unstable.

Implementation Trade-offs

Two primary patterns exist to handle this behavior:

• Model-Flag Gating: Using a Maybe String or boolean in the model to track in-flight requests. The update function ignores new requests until the current one returns a result.
• Idempotency Keys: Generating a unique identifier for the request and including it in the payload, shifting the deduplication responsibility to the server.

Model-side gating simplifies the server but can lead to a locked UI if error handling is not exhaustive. Conversely, idempotency keys allow for more aggressive retry strategies but require a server capable of tracking and ignoring duplicate keys.

Technical Questions

Which approach provides better reliability when handling transient network timeouts where the client is unsure if the server received the original request? In what scenarios does model-state gating become an architectural bottleneck compared to server-side idempotency?