Mendix uses Eclipse Jetty as its underlying web server. Jetty is fast and memory-efficient, but it still depends on the HTTP connection lifecycle. Since the microflow runs for about 10 minutes, the browser–server connection is likely closed during this time. The microflow completes in the background and your custom “process is done” log is written. However, when Mendix then tries to send a popup or UI update back to the client, the connection is already closed, so Jetty throws a “broken pipe / EOF” error.
It’s also worth checking this: was the microflow started asynchronously (background) or synchronously, tied to the UI request?
Hi,
The error you see (EofException, Broken pipe, JSON serialization error at the very end) is not an issue with your microflow logic itself — it happens because the client (browser) connection closes before Mendix finishes returning the result.
In Mendix:
UI-triggered microflows run in the HTTP request/response cycle.
If a microflow takes a very long time, the client connection times out or is closed before Mendix can send the final response back.
When Mendix tries to serialize and send the end result to the client, it fails with Broken pipe / EofException because the connection is gone.
This is expected behavior for long synchronous calls.
Why this isn’t a memory leak
The server finished processing and committed data correctly.
The error happens only when writing back to the client.
It does not mean your data is corrupted or leaked.
Why UI updates or popups fail
Because the connection was closed before the response was sent, the UI never receives the success response — so the popup and screen refresh won’t show.
Best Practice (professional approach)
For long-running operations like this:
✅ Run the microflow in the background (Task Queue or async) instead of directly from the UI.
In Studio Pro, enable Execute this microflow in a Task Queue on the Call Microflow activity.
Background tasks are not tied to the client HTTP connection.
This ensures:
The UI doesn’t time out.
The process completes independently.
You can notify the user later (e.g., via notification, polling, status entity).
Alternative UI pattern
If you must start from the UI:
Have a short microflow trigger the background task.
Immediately return to the UI.
Let the client poll or check status periodically to show progress or completion.