When processing a large volume of data, an issue occurs where the microflow does not return control to the calling nanoflow. Please let me know the possible causes and how to investigate this issue.

0
When operating on a large volume of data, an issue occurs where the microflow does not return control to the calling nanoflow.We suspect that memory exhaustion on the client side may be the cause; however, could you advise on what other possible causes should be considered and provide any specific investigation methods if available?
asked
2 answers
0

If the microflow retrieves a large number of objects and the loop takes a long time to complete, it may hit a timeout, which can prevent control from returning to the nanoflow. If this is the case, I recommend implementing a batch processing structure inside the microflow. This allows the data to be processed in smaller chunks, improving both performance and stability.


Alternatively, you can trigger the microflow asynchronously from a button instead of calling it from a nanoflow. This way, the microflow runs in the background without blocking the UI. For this approach, the microflow should not be called from a nanoflow, because nanoflows are synchronous and will wait for the microflow to finish.


answered
0

hi,


If you call a microflow from a nanoflow and it never returns control, this is usually not about memory on the client. It’s about how Mendix handles long server work.

Why this happens

When a nanoflow calls a microflow:

  • The nanoflow waits synchronously for the server to finish
  • If the microflow does a lot of work (big loops, many commits, lots of data), it takes a long time
  • The client waits until the server finishes
  • If the server takes too long, the call may timeout before returning

So it looks like it never returns, but the server may still be working behind the scenes.

This is how Mendix nanoflow → microflow works (documented behavior).

The real common causes

1. Server timeout

Cloud and browsers have limits on how long a request can stay open. Long microflows can exceed that.

2. Too much data returned to the client

If the microflow returns huge lists or large objects, the response gets slow and may never reach the client fast enough.

3. Heavy logic / many database operations

Inside the microflow:

  • looping large lists
  • committing inside loops
  • complex logic
  • all slow down execution.

The client just waits until the server completes.

What to do instead

Instead of running heavy logic in a synchronous microflow:

Use asynchronous execution

  • Trigger the microflow in the background
  • Let the UI continue immediately
  • Notify the user when processing is done

Use Task Queue (best practice)

Mendix has a Task Queue for long jobs — this keeps the UI responsive and avoids timeouts.

Return only needed data

If a microflow must return something to the client, return a small result, not the whole dataset.

answered