Page keeps loading forever after upgrading from Mendix 9 to 10, no errors at all Post:

0
Hi everyone, I’m a bit stuck and honestly running out of ideas, so hoping someone here might have seen this before. I recently upgraded my app from Mendix 9 to Mendix 10. Everything was working perfectly fine in Mendix 9, but after the upgrade one of the pages just refuses to load. The loader keeps spinning and the page never opens. What makes this really confusing is that there are no errors anywhere. The app deploys fine, there are no runtime exceptions, and nothing critical shows up in the browser console either. I only see some warnings about deprecated meta tags, deprecated mx.logger, and slow network / fallback fonts, but nothing that actually explains why the page is stuck. All the data seems fine, URLs are coming correctly, static resources are accessible, and again, the exact same setup worked without any issue in Mendix 9. This happens consistently in Mendix 10, including in the test environment. It feels like something that Mendix 9 was silently allowing, but Mendix 10 is now behaving more strictly and getting stuck without throwing any clear error. Since there’s no obvious failure point, it’s really hard to debug what’s actually blocking the page lifecycle. Has anyone experienced something similar after upgrading from Mendix 9 to Mendix 10, where a page just keeps loading endlessly without errors? Is this a known behavior change in Mendix 10, or is there any recommended way to track down what’s causing this kind of silent infinite loading? Any help or pointers would be greatly appreciated. Thanks!
asked
2 answers
0

Problem Summary (What is actually happening)

After upgrading from Mendix 9 to Mendix 10, a page:

  • Keeps loading forever (spinner never stops)

  • Shows no runtime errors

  • Shows no clear browser console errors

  • Works perfectly in Mendix 9

  • Fails consistently in Mendix 10 (including Test environment)

This is a classic Mendix 9 → 10 migration issue, and the key detail is this:

Mendix 10 introduced stricter client lifecycle handling, stricter data loading rules, and more async behavior in pages, nanoflows, and widgets.

So what Mendix 9 silently tolerated, Mendix 10 will wait on forever if something never resolves — without necessarily throwing an error.

Why This Happens in Mendix 10 (Root Causes)

An endless page loader in Mendix almost always means:

The page is waiting for something that never completes

In Mendix 10, this usually comes from one of the following five categories.

1. Page Datasource Microflow / Nanoflow Never Returns Properly

Why Mendix 10 behaves differently

In Mendix 9:

  • A datasource microflow could return empty, null, or partially loaded data

  • The client sometimes still rendered the page

In Mendix 10:

  • The page will not render until the datasource finishes cleanly

  • If the microflow:

    • Never reaches an End Event

    • Hits a loop condition

    • Waits on async logic

    • Returns an invalid object→ The loader spins forever

How to confirm

  1. Open the page

  2. Check:

    • Page → Data source

    • Context widget → Microflow/Nanoflow

  3. Put a log statement at the very first and very last activity of the microflow

Start → Log "Datasource START"
End → Log "Datasource END"

If you see START but not END in the logs, you’ve found the issue.

Common mistakes after upgrade

  • Microflow returns empty list when page expects single object

  • Microflow returns null object

  • Exception is caught silently and flow ends without return

  • Retrieve with XPath that now fails due to security changes

Fix

  • Ensure the microflow:

    • Always reaches End Event

    • Always returns the correct type

    • Handles empty results explicitly

Best practice:

If retrieved object = empty
→ Create empty helper object
→ Return helper

2. Nanoflow + JavaScript Action Deadlock (Very Common in M10)

Why this breaks in Mendix 10

Mendix 10:

  • Uses modern async JS execution

  • Nanoflows are fully asynchronous

  • If a JavaScript action:

    • Never resolves

    • Never calls resolve()

    • Waits for something unavailable→ The nanoflow never finishes→ Page never loads

Mendix 9 was more forgiving and often ignored this.

How to identify

Check if the page has:

  • Nanoflow datasource

  • On Page Load nanoflow

  • Widgets that internally use nanoflows

Then inspect any JavaScript actions used inside.

Typical problematic JS code

return new Promise((resolve, reject) => {
    // async logic
    // resolve() is never called
});

Fix

Ensure every JavaScript action:

  • Calls resolve(value)

  • Or reject(error)

  • Never exits silently

Add logging inside JS actions:

console.log("JS Action started");
console.log("JS Action resolved");

3. Custom Widgets Not Fully Mendix 10 Compatible

This is one of the TOP causes

Even if:

  • Widget loads

  • No error in console

  • App compiles

The widget may:

  • Block page rendering

  • Break React lifecycle

  • Never notify Mendix that it is “ready”

Why no error is shown

React 18 (used in Mendix 10):

  • Suppresses some lifecycle errors

  • Fails silently in production mode

How to test quickly

  1. Duplicate the page

  2. Remove all custom widgets

  3. Test page load

If it loads:

  • Add widgets back one by one

  • You’ll find the blocker

Typical problematic widgets

  • Old community widgets built for Mx 8/9

  • Widgets using:

    • mx.data.subscribe

    • Deprecated client APIs

    • Direct DOM manipulation

Fix

  • Upgrade widget to Mendix 10 compatible version

  • Replace with Marketplace alternative

  • Rebuild custom widget using Mx 10 widget framework

4. Conditional Visibility Depending on Data That Never Arrives

Subtle but dangerous change in Mendix 10

In Mendix 10:

  • Conditional visibility is evaluated asynchronously

  • If visibility depends on:

    • Attribute of a context object

    • Association retrieve

    • Expression referencing unloaded data→ Page waits

Example

Visible if: $CurrentObject/MyModule.Status = 'Active'

If:

  • $CurrentObject is empty

  • Or association is not retrieved yet→ Visibility condition never resolves

Fix

  • Guard all expressions:

$CurrentObject != empty and $CurrentObject/MyModule.Status = 'Active'

  • Avoid deep association chains in visibility

  • Preload required data in datasource microflow

5. Access Rules / Entity Security Change After Upgrade

Why Mendix 10 breaks silently

Mendix 10 enforces:

  • Entity access

  • Attribute access

  • Association access

More strictly at runtime.

If:

  • Page retrieves data the user role no longer has access to

  • Access error happens during page load→ Client waits for data→ No visible error

How to detect

Enable Trace logging for:

Client
Security
MicroflowEngine

Then reload page.

Fix

  • Re-validate:

    • Entity access rules

    • Attribute access

    • XPath constraints

  • Especially for:

    • Admin vs User roles

    • System.User associations

    • Cross-module associations

Recommended Step-by-Step Debug Strategy (Use This Order)

  1. Check page datasource microflow

    • Add start/end logs

  2. Disable all widgets

    • Confirm page loads

  3. Check nanoflows and JS actions

    • Especially async ones

  4. Simplify conditional visibility

    • Add empty checks

  5. Revalidate security

    • Especially after domain model changes

  6. Enable verbose logging

    • Client + MicroflowEngine

Why There Are No Errors (Important Insight)

This is not a bug — it is by design in Mendix 10.

The page loader spins because:

  • Mendix client is waiting

  • Nothing explicitly failed

  • Something never completed

Mendix 9 often:

  • Ignored incomplete promises

  • Rendered partial pages

  • Masked bad patterns

Mendix 10 exposes those flaws.

 

 

answered
0

Could you check App Settings → Runtime → Use React Client and see whether it is set to Yes or Migration mode?

 

With Mendix 10, the client is moving from Dojo-based widgets to React, and this often causes client-side issues, especially after an upgrade. Problems like endless loading can happen because some legacy widgets or layouts behave differently in Migration mode.

 

Even when running locally, this issue can still occur. If this setting is currently enabled, could you try setting it to No, redeploy the app, and test again to see if the page loads correctly?

answered