Http.Error Timeout variant without configurable timeout in Elm 0.19

Direct Answer

Use Task.race to pit Http.toTask request against a Process.sleep ms |> Task.andThen (always (Task.fail Timeout)) task, tagging both with a unique requestId. In update, keep a Dict RequestId RequestState in your model and discard any response whose requestId is absent or marked Cancelled. This guarantees exactly one state transition per logical request.

Why This Works

Elm 0.19's Http.request exposes no timeout parameter; the Http.Error.Timeout variant only surfaces when the browser's native timeout fires (typically 30–300 seconds, unconfigurable from Elm). The runtime cannot abort the underlying fetch/XHR, so both the success and the application-level timeout task can complete. The requestId guard in the model makes the second arrival a no-op, yielding a single, final transition.

Minimal Reusable Pattern

type alias RequestId = Int

type RequestState = Pending | Completed | Cancelled

withTimeout : Int -> Request -> (Result Http.Error a -> msg) -> (RequestId, Cmd msg)
withTimeout ms request toMsg =
    let
        requestId = nextRequestId model
        timeoutTask =
            Process.sleep ms
                |> Task.andThen (always (Task.fail (Http.Timeout "application timeout")))
        racedTask =
            Task.race (Http.toTask request) timeoutTask
                |> Task.map (toMsg requestId)
    in
    ( requestId
    , Task.perform identity racedTask
    )

In update, on toMsg requestId result:

1. If requestId not in model.pending → ignore.
2. If result is Ok → update state to Completed, remove requestId, process payload.
3. If result is Err Timeout → update state to Cancelled, remove requestId, handle timeout.

Bandwidth and Timer Leaks

Bandwidth cannot be saved—the browser continues the download regardless. The pattern only prevents duplicate state transitions. Timer leaks are avoided because Task.race cancels the losing task internally; removing the requestId from the pending dict ensures a late timeout message becomes a no-op without any lingering Process.sleep references.

Verification Steps

1. Fire two rapid requests with a 50 ms application timeout; log requestId in update and confirm only one message per request reaches the update function.
2. Open the Network tab: observe that the browser request continues after the Elm timeout fires.
3. Mount/unmount the component rapidly; verify no stray timeout messages appear in the console.

Assumptions and Uncertainty

• Assumes Elm 0.19.0–0.19.1; behavior unchanged in current 0.19.x releases.
• Assumes Task.race cancellation semantics are as documented (winner cancels loser).
• If you use Task.perform instead of Task.attempt, ensure the timeout task shares the same requestId so cancellation logic stays symmetric.

One diagnostic detail that would change the recommendation: are you using Http.expectString or a custom Http.Expect? Custom expectations may require wrapping the expectation itself in the race rather than the raw request.