mxcli v0.25.0: after-startup left as MxTest.RegisterEndpoint, which then calls itself (StackOverflowError, app won't start) #244

Found while building three apps side by side. Two hits in one day, one of them took an app down.

mxcli v0.25.0 (2026-10-05T09:18:28Z), Mendix 11.15.0, macOS. Two observations, same family.

Observation 1 (app A):

• Setup:
  • mxcli run -p AppA.mpr --local --test-endpoint --app-port 8086 ... was running.
  • That run rewrote the project-settings unit on disk (mprcontents/4e/70/4e70063d-….mxunit): AfterStartupMicroflow went from SupplyRisk.ASU_Startup (HEAD) to MxTest.RegisterEndpoint (working tree). It also added one extension unit (mprcontents/08/89/0889c4b4-….mxunit).
• Action: in the same project folder, mxcli test tests/some.test.mdl -p AppA.mpr --local (ports 8081/8091 were free).
• Symptom:

  ERROR - Core: An exception occurred while running the after-startup-action.
  com.mendix.modules.microflowengine.MicroflowException: java.lang.StackOverflowError
      at MxTest.RegisterEndpoint (SubMicroflow : 'RegisterEndpoint')
      at MxTest.RegisterEndpoint (SubMicroflow : 'RegisterEndpoint')
      ... (repeated)
  ERROR - M2EE: Starting Mendix Runtime failed.
  Caused by: com.mendix.m2ee.api.InfoAdminException: The after-startup-action failed with an exception or returned false.
  Error: local runtime: starting runtime: start failed: class com.mendix.m2ee.api.InfoAdminException occurred while executing an admin action request.
  

  Exit 1, no test ran.
• Likely cause: the test harness wraps "the current after-startup microflow" with MxTest.RegisterEndpoint, which then chains to the original. Because the original is already MxTest.RegisterEndpoint, it ends up calling itself.
• Not affected: the running 8086 app.
• Workaround: a git worktree of HEAD (after-startup = ASU_Startup) plus the units under test, on 8081. 8/8 there.
• (The failing log file was later overwritten by the passing run; the lines above are verbatim from it.)

Observation 2 (app B): app B's outage on 8087 this round has the same cause. An interrupted test run left app B's after-startup set to MxTest.RegisterEndpoint, so the app's next start called itself the same way and app B did not come up.

What upstream should probably do:

• Never wrap when the after-startup is already MxTest.RegisterEndpoint, or detect the self-reference.
• Restore the original after-startup on interrupt (signal or crash), not only on a clean exit.
• With run --test-endpoint, keep the injection out of the on-disk model (or restore it on exit) so a second mxcli process does not see it.

🤖 Generated with Claude Code