Hi Patrik Cumurdzic
This is a known Email Connector bug: after a long IMAP downtime, the connector’s IMAP session gets stuck. It logs “fetch complete!” but never reconnects until the Mendix app restarts.
Why: Session dies on SocketTimeoutException, but the connector doesn’t recreate the IMAPStore.
Fixes / Workarounds:
It looks like the problem started when the mail server was down and the connector failed to create a session. The key error is:
EC0x019: Error while creating session
caused by
SocketTimeoutException: Connect timed out
So when the IMAP server was unavailable, the Email Connector could not establish the connection. After the server came back, the scheduled event kept running and logging fetch complete!, but it seems the connector did not properly recover its connection state. That’s why no new emails were fetched.
The fact that everything works again after restarting the Mendix app strongly suggests that the connector was stuck in a bad state and the restart forced it to create a fresh connection/session.
A few things you could check:
First, make sure you are using the latest version of the Email Connector module, since recovery after connection failures might have been improved in newer versions.
Second, review the microflow that runs in the scheduled event. If the connection fails, it is worth handling that exception explicitly and making sure the connector/session is reinitialized instead of continuing as if the fetch succeeded.
Also, manual fetch not working during that time is a strong sign that the issue is probably not the scheduled event itself, but the connector session getting stuck after the timeout.
So my guess is that the connector did not recover cleanly after the IMAP timeout, and restarting the Mendix runtime reset that state.
If this resolve your issue, please close the topic.
Hi,
This is a known behavior with the Email Connector receive flow when the IMAP connection fails while the batch task is running. What is happening in your case is that when the mail server was unavailable, the connector failed while creating the IMAP store:
MailConnectException / SocketTimeoutException
After that failure the ReceiveEmailBatchTask thread remains alive but the IMAP session/store is already invalid. The scheduled event keeps triggering the receive logic every 5 minutes, but internally the connector is still holding that broken state, so it logs:
Email_Connector: fetch complete!
even though it is not actually reconnecting to the mail server.
When you restart the Mendix runtime the whole mail session and IMAP store are recreated, which is why on the first run after restart all the missing emails are fetched.
Manual fetch calls the same ReceiveEmailHandler logic, which uses the existing store/session. Since the store was already in a failed state, it never re-established a fresh connection.
The safest way to avoid this is to force the connector to create a new session each time it runs, instead of relying on the previous handler state.
Typical implementation:
Example pattern:
Scheduled Event
→ Custom MF_FetchEmails
→ Call ReceiveEmail (Email Connector)
→ Error handling = Custom
If the receive fails:
Catch exception Log error End microflow
This prevents the failed batch task from keeping a broken state.
1. Upgrade the Email Connector module
Older versions of the Email Connector had several issues around IMAP reconnects and stale sessions. Make sure you are using the latest version compatible with Mendix 10.
2. Reduce connection timeout
If your mail server occasionally becomes unavailable, configure a lower IMAP timeout so the connector fails quickly and retries in the next scheduled execution.
3. Avoid long-lived sessions
Make sure the receive logic does not keep a persistent IMAP session between runs.
The issue is not that Mendix stops fetching emails. The problem is that the Email Connector keeps a broken IMAP session after the server outage, so subsequent fetches run but do not reconnect.
Restarting the app fixes it because it forces a new IMAP session. Implementing proper error handling and ensuring a fresh session per scheduled run prevents the issue without needing to restart the runtime.