The error message usually indicates a timeout on the browser or the user navigating away.
Is the page data-heavy? If it is data-heavy, can the page be refactored at all? Removing some of the data to other pages for example, or adding indexes to speed up data retrieval.
Hello Joey
This error, org.eclipse.jetty.io.EofException: null, is a classic "Broken Pipe" scenario in Mendix. It essentially means that the Mendix Runtime (the server) was ready to send the final response back to your browser, but the browser (the client) had already "hung up" or closed the connection.
Because the connection is gone, the client-side JavaScript never receives the "Finished" signal, so it stays in the loading state indefinitely.
Since you mentioned this happens when navigating from the Home Page, check if a user might be double-clicking or navigating away before the first request finishes.
The Scenario: A user clicks a button to open an object. The browser starts a request. If the user clicks again or clicks something else immediately, the browser cancels the first request.
The Result: The Mendix server continues processing the microflow (which is why your logs show it completes), but when it tries to return the result, the browser has already closed the "door."
Maybe try to use the mx-progress bar default behaviour from Mendix which should prevent the user from clicking something else.
If it's a button action you may try to 'show progress message'
If it's not you could try to do it via a nanoflow and use the nanoflow activities for show message & hide message and do the action in between.
The endless loading bar together with an EofException usually indicates that the client connection was closed before the server could send back the response. In this situation, the microflow may still complete successfully on the server, but because the browser no longer waits for the response, the UI never receives the completion signal and the loading indicator keeps spinning. This can be improved by ensuring the UI remains blocked while the microflow is running, for example by relying on Mendix’s default progress behavior or by explicitly controlling progress handling in a nanoflow. It is also worth reviewing long-running logic and moving heavy processing out of synchronous UI flows where possible, so the client does not time out or lose the connection before the response is returned.
Hi thanks for the answers!
I've tried using the progress bar and made it blocking so no other request can be asked while the microflow is still running. But with no succes.
I'll try using a Nanoflow next.