Duplicate Http requests when retrying in Elm 0.19

Why duplicate Cmds appear

In Elm 0.19 the Http module does not track in‑flight requests. If the same Msg that triggers an Http.send is emitted again before the previous response is handled, the runtime will emit an identical Cmd, causing the backend to see two identical calls.

Confirmed pattern to avoid duplicates

1. Extend the Model with a set of pending request identifiers:

type alias Model = {
    pending : Set String,
    -- other fields …
}

2. When you create a request, generate a unique ID (e.g., a UUID v4 or a deterministic hash of the payload) and store it:

sendRequest : Request -> Cmd Msg
sendRequest req =
    let
        id = generateId req   -- pure function returning a String
        cmd = Http.send ExpectResponse (Http.request { method = "POST", url = "/api/op", body = Http.jsonBody req.payload, headers = [ Http.header "Idempotency-Key" id ] })
    in
        ( { model | pending = Set.insert id model.pending }, cmd )

3. In update, before emitting a retry Msg, check that its ID is not already in pending:

update msg model =
    case msg of
        RetryOp req ->
            let id = generateId req
            in if Set.member id model.pending then
                    ( model, Cmd.none )   -- duplicate suppressed
                 else
                    sendRequest req
        ResponseOk _ ->
            ( { model | pending = Set.delete id model.pending }, Cmd.none )
        ResponseErr _ ->
            ( { model | pending = Set.delete id model.pending }, Cmd.none )
        -- …

4. Remove the ID from the set on any terminal response (success or error) so a later retry can reuse the same logical operation.

Idempotency‑key handling

If your backend supports the Idempotency-Key header, include the same generated ID on every attempt (as shown above). This lets the backend safely ignore retries even if Elm accidentally emits a duplicate Cmd. If the backend does not honor this header, the only guarantee comes from the pending set check in update.

What to verify

• Does your backend treat the Idempotency-Key header as deduplication?

Answering that question determines whether you rely solely on the Elm‑side set or also need the header for safety.