Workflow: dangling `jump to` target is silently stored as a self-referencing jump (check + exec pass, native mx check fails CE6681)

[MendixMau]

Summary

A jump to <name> whose target does not match any activity name is silently accepted by mxcli check --references and by mxcli exec. mxcli then writes the JumpToActivity with its own Name set to the missing target string and TargetActivity pointing at that same string — a jump that targets itself. The native Mendix validator rejects the stored model with CE6681 "It is not possible to jump to end activities or jump-to activities.", which names the wrong problem: the real fault is an unresolved target, not an illegal target type.

This is a write-path defect (verified in the stored BSON, not from a read-back command), and it is reachable from DESCRIBE WORKFLOW output — see "Why this is easy to hit" below.

Environment

• mxcli v0.20.0 (2026-08-28T13:22:53Z), mxcli-darwin-arm64 from the tagged v0.20.0 release
• Mendix model version 11.13.0
• Gate: mx from Mendix Studio Pro 11.13.0 Beta, invoked via mxcli docker check
• macOS (darwin arm64)

Steps to reproduce

repro.mdl (substitute any existing microflow taking one entity-typed parameter, and any page):

create workflow ProcessCore.WF_JumpRepro
  parameter $WorkflowContext: ProcessCore.ProdOpenPackage
begin
  call microflow ProcessCore.SUB_WF_OpenPackage with (Package = '$WorkflowContext') -- StepA
    outcomes DEFAULT -> { };
  call microflow ProcessCore.SUB_CheckPackageAvailability with (Package = '$WorkflowContext') -- StepB
    outcomes
      true -> { }
      false -> {
        jump to callMicroflow2 comment 'back to StepB';
      };
end workflow;

Note callMicroflow2 does not exist in this model — that is the entire trigger.

$ mxcli check repro.mdl -p App.mpr --references
✓ Expression types OK

Check passed!

$ mxcli exec repro.mdl -p App.mpr
Connected to: App.mpr (Mendix 11.13.0)
Created workflow: ProcessCore.WF_JumpRepro

$ mxcli docker check -p App.mpr
[error] [CE6681] "It is not possible to jump to end activities or jump-to activities." at Jump 'back to StepB'
The app contains: 1 errors.

What was actually stored (BSON, not read-back)

strings -n 3 on the workflow's mprcontents/**.mxunit:

$Type
Workflows$JumpToActivity
Caption
back to StepB
Name
callMicroflow2          <-- the jump activity is NAMED after the missing target
TargetActivity
callMicroflow2          <-- ...and points at that same name, i.e. at itself

For contrast, the call-microflow activity in the same unit is stored as:

$Type
Workflows$CallMicroflowActivity
Name
SUB_CheckPackageAvailability

So call-microflow activities are auto-named after the microflow they call, while an unresolved jump is auto-named after the string it failed to resolve.

Expected

One of:

1. mxcli check --references fails with a clear diagnostic — e.g. jump target 'callMicroflow2' does not match any activity in this workflow — listing the valid activity names; and/or
2. mxcli exec refuses to write a JumpToActivity whose TargetActivity resolves to no activity.

In no case should the jump be given the missing target's name, which converts an unresolved-reference error into a self-reference error and misdirects the resulting CE6681.

Actual

check --references passes, exec reports success, and the defect surfaces only under the native validator, as an error whose text describes a different fault.

Trigger boundary

jump to <target>	mxcli check --references	mxcli exec	native mx check
name of a real activity (SUB_CheckPackageAvailability)	pass	pass	0 errors
name matching no activity (callMicroflow2)	pass	pass	CE6681

Confirmed by dropping the workflow and re-running with only the target string changed; with the correct name, a 23-activity workflow (14 CALL MICROFLOW, a DECISION, a non-interrupting boundary timer, a WAIT FOR TIMER, two user tasks with XPath targeting, and two jumps) validates at 0 errors. The jump machinery itself is sound — only the unresolved-target path is broken.

Why this is easy to hit

DESCRIBE WORKFLOW emits jump targets using the source model's activity names, but a scripted rebuild derives call-activity names from the called microflow. So the natural describe → edit → exec loop produces exactly this defect: the emitted jump to callMicroflow6 referred to an activity that existed in the original model and does not exist in the rebuilt one. Everything on the mxcli side reports success.

Severity

Verified on Mendix 11.13.0 with mxcli v0.20.0: a silently malformed workflow written to the model, caught only by a validator outside mxcli, and reported there under a misleading error code. Any workflow containing a loop is exposed. Not a read-back/cosmetic issue — the stored bytes are wrong.