fix(workflow): stop naming a jump activity after its target (mendixlabs/mxcli#1005)

[ako]

Fixes mendixlabs/mxcli#1005. Independent of the two describe PRs — branches off main.

buildJumpTo set the jump activity's Name to its target's name. Mendix resolves TargetActivity by name, so the jump could resolve to itself, and CE6681 ("not possible to jump to end activities or jump-to activities") then describes a different fault than the real one.

Nothing caught it first. A jump target is the only intra-document reference a workflow has — validateWorkflowStatementRefs resolves microflows, pages and entities, and never looks at activity names. So check --references passed, exec reported success, and the defect surfaced only under the native validator.

A second case, not in the report

A forward jump to a target that does exist breaks identically, because deduplication renames the second activity carrying a name:

	jump's stored Name	real target
backward (target first)	StepB2	StepB	works — the reported "valid target" row
forward (jump first)	StepB	StepB2	self-reference → CE6681

Straight from the control run against unfixed code:

--- FAIL: TestJumpTo_NeverTakesTheTargetsName/forward
    jump is named after its target ("StepB") — it targets itself
    target "StepB" is not the name of any activity; names present: map[StepA:true StepB2:true]

Loops jump backwards, which is why the reported table shows a valid target as safe. Fixing only the unresolved-target case would have left half the bug.

The fix, both ends

• A jump is named JumpTo (deduped JumpTo, JumpTo2, …) so it can never carry a target's name.
• Deduplication runs in two passes with jumps last, so a jump never claims a name a real activity wanted — whatever it is called and wherever it appears.
• MDL-WF05 refuses an unresolved target at check time and, via the same function, in execCreateWorkflow — exec is reachable without check (the mxcli check doesn't flag id = <String> XPath retrieve constraints (CE0161 on real compile) — MDL048 exists in source but isn't in a release yet mendixlabs/mxcli#833 lesson).

The valid-target set comes from running the real builders over the AST, not from re-deriving names here: a call microflow M.SUB_X activity is named SUB_X, and a second copy of that rule would drift into exactly the false refusals this rule exists to prevent. No project needed — every name comes from the script. Jumps are excluded from the set, since Mendix refuses a jump to a jump.

The suggestion lists the valid names, because they aren't visible in the script — which is most of why the wrong name is easy to reach, and why describe → edit → exec produces this:

jump target "callMicroflow2" does not match any activity in this workflow — Mendix
resolves a jump by activity name, so this is written as a jump to itself and the build
fails with CE6681 (...)
  → Valid targets in this workflow: SUB_CheckPackageAvailability. A `call microflow`
    activity is named after the microflow it calls.

Tests

Eight, verified against unfixed code (three fail, including the forward case above). Controls that matter: a valid jump in both directions must not be flagged (otherwise the rule could pass by refusing everything), a target nested in an outcome flow must resolve (otherwise every jump into a branch is refused), and two jumps in one workflow must get distinct names.

That last one earned its place immediately — a careless bulk edit left if jumpPass { if !jumpPass { in the dedup, silently disabling all jump renaming. Only the uniqueness test caught it; CE0495 would have been the next bug report.

🤖 Generated with Claude Code