Nanoflow writer hardcodes ErrorHandlingType="Rollback"; Studio Pro rejects CreateList/ChangeList in nanoflows (CE6035)

[ako]

Problem

When a nanoflow contains a create list of … or add … to list activity, mx check rejects the project with CE6035 "Error handling type is not supported". The same error fires for call nanoflow … on error continue.

Reproduction (originally hit while expanding mdl-examples/doctype-tests/02b-nanoflow-examples.mdl):

create non-persistent entity NfBug.Summary ( Name : String(200) );
create entity NfBug.Product ( Name : String(200) );

create nanoflow NfBug.DS_Summaries ()
    returns List of NfBug.Summary
begin
    retrieve $Products from NfBug.Product;
    $Summaries = create list of NfBug.Summary;
    loop $P in $Products
    begin
        $S = create NfBug.Summary (Name = $P/Name);
        add $S to $Summaries;
    end loop;
    return $Summaries;
end;

mx check output on the resulting MPR:

[error] [CE6035] "Error handling type is not supported" at Create list activity 'Create list of Summary'
[error] [CE6035] "Error handling type is not supported" at Change list activity 'Add to list Summaries'

Root cause

sdk/mpr/writer_microflow_actions.go unconditionally writes ErrorHandlingType: "Rollback":

• CreateListAction — hardcoded "Rollback" (line 386)
• ChangeListAction — hardcoded "Rollback" (line 399)
• NanoflowCallAction — defaults to "Rollback" via stringOrDefault (line 251)

Dumping Viewer3D.GetModelListFromMendix from the LatoProductInventory reference project (authored in Studio Pro) shows the same activities use "Abort" in a nanoflow context:

$ mxcli -p LatoProductInventory.mpr bson dump -t nanoflow -o Viewer3D.GetModelListFromMendix | grep -B1 -A1 ErrorHandlingType
  "Key": "ErrorHandlingType", "Value": "Abort"
  ...

So the writer is using the microflow default ("Rollback") for activities serialized inside a nanoflow. The shared serializeMicroflowAction path has no nanoflow-vs-microflow context to switch on.

Note: NanoflowCallAction with the default Rollback happens to be accepted by mx check, but explicit on error continue (which writes "Continue") is rejected. The hardcoded default papered over the bug for the original 02b examples, which only used call nanoflow and no list ops.

Suggested fix

1. Writer — thread an isNanoflow bool flag through serializeMicroflowAction (called from both serializeMicroflow and serializeNanoflow in sdk/mpr/writer_microflow.go:804). When isNanoflow, default ErrorHandlingType to "Abort" for CreateListAction, ChangeListAction, NanoflowCallAction (and likely others — worth a sweep). The existing AST value should still win when explicitly set.
2. AST / executor — surface a nanoflow-friendly default in mdl/types/ so the executor doesn't need to know the writer's convention.
3. MDL surface — add on error abort keyword to the grammar (alongside today's continue / rollback / handler block) so authors can pin the behaviour explicitly. Check the Mendix metamodel for any other nanoflow-only values worth exposing.
4. Test coverage — add a nanoflow loop-and-build-list example to mdl-examples/doctype-tests/02b-nanoflow-examples.mdl (currently removed to keep the test green) so the regression is caught next time. A unit test in sdk/mpr/ that asserts ErrorHandlingType == "Abort" on a list action serialized via serializeNanoflow would pin the writer behaviour.

Why this matters

The loop-and-build-list pattern is the canonical way to project a persistent list into a view-model list in Mendix nanoflows — used heavily across Viewer3D, WorkflowCommons, and the Atlas data-source helpers. Without this fix, mxcli can't faithfully reproduce a large class of real nanoflows.

Found during

Expanding mdl-examples/doctype-tests/02b-nanoflow-examples.mdl with representative patterns from EnquiriesManagement, LatoProductInventory, Evora-FactoryManagement. The expanded file dropped the loop-build-list pattern (Pattern 9 in the original draft) and the call nanoflow … on error continue pattern until this bug is fixed.

[github-actions]

Issue Triage

Summary:
The issue reports that mx check incorrectly rejects nanoflows containing create list of …, add … to list, or call nanoflow … on error continue with error CE6035 because the writer hard‑codes ErrorHandlingType="Rollback" for these activities, whereas nanoflows should default to "Abort".

Checklist of required bug‑report information

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what the user was trying to do)	✅	MDL snippet, mx check command
Expected output	✅	mx check should succeed (no CE6035 errors)
Experienced output	✅	CE6035 errors on Create list and Change list activities
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing:

• The version of mxcli you used (mxcli --version or commit/build info).
• The Mendix version of the project being processed (e.g., 10.6, 9.24).
• A diagnostic bundle or at least the session log from mxcli diag --bundle to help reproduce the environment.

Could you please add those details? Once we have them, we’ll be able to investigate the fix more efficiently. Thanks for the thorough description!

---

Automated triage via OpenRouter — workflow source