Elm ports: missing ordering guarantee between inbound and outbound messages

Direct Answer

The Elm runtime provides no ordering guarantee between messages sent through outgoing ports and those received on incoming ports. Because the Elm-to-JavaScript boundary is intentionally asynchronous, messages flowing in opposite directions are scheduled independently on the JavaScript event loop. Assuming a reply corresponds to the most recent command will lead to race conditions under load.

Likely Explanation and Technical Constraints

The lack of sequencing is a result of how Elm handles its runtime loop and how JavaScript manages the event loop. When an outgoing port is called, the message is dispatched to JavaScript; however, the return path (the incoming port) is a separate subscription. There is no shared queue or synchronization primitive that forces the Elm runtime to wait for a specific response before processing the next internal message or receiving a different port message.

Under high message volume, or when the JavaScript side involves asynchronous operations (such as fetch or setTimeout), the browser's event loop may interleave these messages. This means a response to a first command may arrive after a response to a second command, or even after a third command has already been sent.

Enforcing Deterministic Sequences

Since there are no officially supported libraries that provide deterministic sequencing across the port boundary, the standard pattern is to implement application-level correlation IDs.

• Correlation IDs: Include a unique identifier (e.g., an integer or UUID) in every outgoing message. The JavaScript side must echo this ID back in the corresponding reply.
• Pending Request Tracking: In the Elm Model, maintain a collection (such as a Dict) of pending requests. When a reply arrives, use the echoed ID to look up the original request and resolve the state.
• Asynchronous Redesign: Shift the architecture from a "request/response" mindset to an "event-driven" one, where Elm simply reacts to incoming data regardless of what was previously sent.

Consequences of Synchronous Assumptions

Applications that attempt to force synchronous request/response semantics without correlation IDs typically encounter the following:

• State Corruption: The application updates the model based on a reply that belongs to a stale command.
• Intermittent Failures: The system may appear to work during low-load local development but fail in production environments where network latency or CPU pressure increases event loop interleaving.
• Unpredictable Timing: Relying on microtask timing (e.g., Promise.resolve()) is unreliable because the Elm scheduler may yield between port operations.

Verification Steps

To verify this behavior in your specific environment, you can perform the following test:

1. Create an outgoing port and an incoming port.
2. Rapidly send a large batch (e.g., 1,000) of numbered messages from Elm.
3. Configure the JavaScript side to immediately send the number back via the incoming port.
4. Log the order of arrival in Elm; any deviation from the sent sequence confirms the lack of ordering guarantees.

One diagnostic detail: Does your JavaScript implementation use Web Workers or iframes to process these ports? If so, the probability of reordering increases significantly due to additional event-loop hops.