Unordered responses when batching elm/http commands with Cmd.batch

Direct Answers

Does Cmd.batch guarantee dispatch order? No. The Elm runtime treats batched commands as independent effects; underlying JavaScript HTTP calls may be issued in any order or concurrently.

Are response Msgs guaranteed to arrive in request order? No. Each HTTP response becomes a separate message scheduled by the browser's event loop. Network latency and server processing time determine arrival order, not the original command list.

Is Task.sequence the only documented way to enforce strict sequencing? Yes. Converting each Http.request to a Task via Http.toTask (available since elm/http 2.0.0), sequencing them with Task.sequence, and performing the result via Task.perform yields ordered dispatch and ordered delivery.

Why This Happens

The Elm runtime processes one message at a time through the sequential update loop. Cmd.batch merely combines multiple commands into a single command value; it does not impose a scheduling discipline on the JavaScript side. When you batch three Http.get calls, the runtime hands all three to the JavaScript HTTP layer, which typically fires them concurrently. Responses return as independent browser events, each queued as a separate message. The update function then runs once per response, but the sequence of those invocations reflects network timing, not your source list order.

Enforcing Order When You Need It

If correctness depends on response order (e.g., request B uses data from request A), refactor to Task.sequence:

requests : List (Http.Request ResponseType)
requests = [ reqA, reqB, reqC ]

batchTask : Task Http.Error (List ResponseType)
batchTask = Task.sequence (List.map Http.toTask requests)

-- In update:
Task.perform BatchResult batchTask

This chains the tasks so each request starts only after the previous one completes, guaranteeing both dispatch and delivery order.

Verification Steps

1. Create a minimal Elm program that batches three Http.get requests to a test endpoint (e.g., httpbin.org/delay/1 with varying delays) and logs the arrival order of the resulting messages.
2. Observe that responses arrive out of order under Cmd.batch.
3. Replace the batch with Task.sequence (List.map Http.toTask requests) |> Task.perform BatchResult and verify responses now arrive in request order.
4. Consult the Elm Guide "Effects" chapter and the elm/http package documentation for Http.toTask and Task.sequence examples.

Version Note

These semantics have been consistent since Cmd.batch was introduced in Elm 0.17. The exact minor version of elm/http 2.x does not change them; Http.toTask exists in all 2.x releases. If your application pins an older 1.x version, the same lack of guarantees applies, but Http.toTask is unavailable—you would need to wrap requests in Task.perform manually.