Merge remote-tracking branch 'origin/main' into HEAD

Author: hjothamendix

.claude/skills/debug-bson.md

@@ -9,6 +9,7 @@ Use when encountering:
 - **Studio Pro crash on open** with `RevStatusCache.CreateDeleteStatusItem` in stack trace
 - **`mx diff` crash** with "Sequence contains no matching element"
 - **CE1613** "The selected attribute/enumeration no longer exists"
+- **CE0115** "The arguments that are passed to page X do not match the expected parameters"
 - **CE0463** "The definition of this widget has changed"
 - **CE0642** "Property X is required"
 - **CE0091** validation errors on widget properties
@@ -306,6 +307,51 @@ for t, props in crash_props.items():
 
 **Fix**: Extract a fresh template from a project with `mx update-widgets` applied. The Type section must match the installed widget version exactly.
 
+### CE0115: Arguments Passed to Page Do Not Match Expected Parameters
+
+**Symptom**: `mx check` reports `[CE0115] "The arguments that are passed to page 'X' do not match the expected parameters."` on an action button that uses `show_page TargetPage (Param: $currentObject)`.
+
+**Root cause**: The BSON array type indicator rule. Every Mendix BSON array must begin with an `int32` **type indicator** of `2` or `3`. This indicator is skipped by `extractBsonArray` and by Studio Pro's reader. Writing `int32(len(items))` as the first element instead produces an invalid indicator when `len ≠ 2` and `len ≠ 3` — Studio Pro cannot recognise the array and reads 0 parameter mappings.
+
+**Type indicator values**:
+| First element | Meaning |
+|---------------|---------|
+| `int32(3)` | Initialized array — used for `Items`, `DesignProperties`, and most non-empty lists |
+| `int32(2)` | Initialized empty array — used for `ParameterMappings`, `PagesForSpecializations`, `Parameters` |
+| Any other value | **Invalid** — Studio Pro ignores the entire array |
+
+**How Studio Pro stores page parameter mappings**: Studio Pro does **not** store explicit `Forms$PageParameterMapping` objects in BSON. It always writes `ParameterMappings: [2]` (type indicator only, no inline objects) and infers `$currentObject` at runtime from the enclosing widget context — DataGrid row, DataView datasource, etc. No matter what the MDL source specifies for `(Param: $currentObject)`, the correct serialization is always the empty `[2]` array.
+
+**Correct writer pattern for `Forms$FormAction`**:
+```go
+formSettings := bson.D{
+    {Key: "$ID",               Value: idToBsonBinary(generateUUID())},
+    {Key: "$Type",             Value: "Forms$FormSettings"},
+    {Key: "Form",              Value: pageName},          // BY_NAME_REFERENCE
+    {Key: "ParameterMappings", Value: bson.A{int32(2)}}, // always empty; runtime infers mapping
+    {Key: "TitleOverride",     Value: nil},
+}
+return bson.D{
+    {Key: "$ID",                    Value: idToBsonBinary(id)},
+    {Key: "$Type",                  Value: "Forms$FormAction"},
+    {Key: "DisabledDuringExecution", Value: true},
+    {Key: "FormSettings",           Value: formSettings},
+    {Key: "NumberOfPagesToClose2",  Value: ""},
+    {Key: "PagesForSpecializations", Value: bson.A{int32(2)}},
+}
+```
+
+**What NOT to do**:
+```go
+// WRONG: produces [1, {mapping}] — invalid type indicator 1
+paramMappings := bson.A{int32(len(a.ParameterMappings))}
+for _, pm := range a.ParameterMappings {
+    paramMappings = append(paramMappings, bson.D{...Forms$PageParameterMapping...})
+}
+```
+
+**Diagnostic check**: Inspect the raw `ParameterMappings` array in a Python BSON dump. If it shows `[1, {...}]` instead of `[2]`, the type indicator is wrong. Studio Pro-generated pages always show `[2]`.
+
 ## Key Principles
 
 1. **Template cloning > building from scratch**: Clone properties from a known-good template Object, then modify only specific values. Building from scratch produces subtly different structures.

mdl-examples/bug-tests/295-showpage-null-variable.mdl

@@ -8,14 +8,45 @@
 -- a non-null Forms$PageVariable embedded object in its Variable field.
 --
 -- Run with: mxcli check 295-showpage-null-variable.mdl
+create module bug295;
 
-CREATE SNIPPET AuditTrail.LogViewer (
-  Folder: 'Snippets'
+create persistent entity bug295.Product (
+  /** Auto-incrementing product ID */
+  ProductId: autonumber default 1,
+  /** Product name (required) */
+  Name: string(200) not null error 'Product name is required'
+);
+
+-- Target page that accepts an entity parameter.
+CREATE PAGE bug295.Product_Detail (
+  Title: 'Product Detail',
+  Url: 'Product_Detail',
+  layout: Atlas_Core.Atlas_Default,
+  Params: { $Product: bug295.Product }
+) {
+  DATAVIEW dv1 (DataSource: $Product) {
+    DYNAMICTEXT txt1 (Content: '$Product/Name')
+  }
+};
+
+-- Overview page with a DataGrid column button that opens the detail page
+-- and passes $currentObject as the page parameter.  This is the scenario
+-- that previously produced a null PageParameterMapping.Variable in BSON.
+CREATE PAGE bug295.Product_Overview (
+  Title: 'Products',
+  Url: 'Product_Overview',
+  layout: Atlas_Core.Atlas_Default
 ) {
-  DATAVIEW dv1 (DataSource: $Log, Editable: false) {
-    ACTIONBUTTON btn_open (
-      Caption: 'Open log detail',
-      Action: SHOW_PAGE AuditTrail.Log_View(Log: $currentObject)
-    )
+  DATAGRID dg1 (
+    DataSource: bug295.Product,
+    Caption: 'Products'
+  ) {
+    COLUMN colName (Attribute: Name, Caption: 'Name')
+    COLUMN colActions (Caption: 'Actions') {
+      ACTIONBUTTON btnDetail (
+        Caption: 'Detail',
+        Action: SHOW_PAGE bug295.Product_Detail (Product: $currentObject)
+      )
+    }
   }
 };

mdl-examples/bug-tests/306-describer-annotations-before-unsupported-comment.mdl

@@ -0,0 +1,61 @@
+-- ============================================================================
+-- Bug #306: Annotations emitted before unsupported-activity comments
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   Activities whose BSON type isn't yet implemented in mxcli's describer
+--   render as `-- unsupported: <Type>` comments. Before the fix, the
+--   describer still prefixed these comment lines with `@position`,
+--   `@anchor`, etc. The grammar only accepts annotations as prefixes of
+--   real microflow statements (not comments), so the resulting MDL failed
+--   to re-parse with errors like:
+--     line N:0 mismatched input '@' expecting {...}
+--
+-- After fix:
+--   When a formatted statement begins with `--`, `emitObjectAnnotations`
+--   is skipped — only the comment is emitted. Annotations on SUPPORTED
+--   activities continue to be emitted as before.
+--
+-- Reproducibility note:
+--   The unsupported-activity branch can only be triggered by an .mpr
+--   containing a BSON activity type that mxcli does not yet describe
+--   (typical examples are very new or rarely-used activity types). Pure
+--   MDL cannot create such an activity. The Go-side regression
+--   `TestTraverseFlow_UnsupportedActivitySkipsAnnotations` covers that
+--   path directly.
+--
+--   This script provides a POSITIVE CONTROL: a microflow whose every
+--   activity carries position / caption / anchor annotations. Its describe
+--   output must (a) parse with `mxcli check`, and (b) round-trip cleanly,
+--   confirming the annotation-emission codepath still works for the
+--   common case.
+--
+-- Usage:
+--   mxcli exec mdl-examples/bug-tests/306-describer-annotations-before-unsupported-comment.mdl -p app.mpr
+--   mxcli -p app.mpr -c "describe microflow BugTest306.MF_AnnotatedFlow"
+--   The output must re-execute cleanly against the same project.
+-- ============================================================================
+
+create module BugTest306;
+
+create microflow BugTest306.MF_AnnotatedFlow (
+  $input: string
+)
+returns string as $result
+begin
+  declare $result string = empty;
+
+  @caption 'log entry'
+  log info node 'BugTest306' 'flow started';
+
+  @caption 'guard'
+  if $input != empty then
+    @caption 'happy path'
+    set $result = 'value: ' + $input;
+  else
+    set $result = 'no value';
+  end if;
+
+  return $result;
+end;
+/

mdl-examples/bug-tests/320-describer-suppress-default-anchor-fragments.mdl

@@ -0,0 +1,55 @@
+-- ============================================================================
+-- Bug #320: DESCRIBE emitted default anchor fragments redundantly
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   `describe microflow` printed `@anchor` lines for every activity, even
+--   when every from/to side matched the MDL default for that flow shape:
+--     - regular sequence flows default to `from: right, to: left`
+--     - true branches of IF default to `from: right, to: left`
+--     - false branches of IF default to `from: bottom, to: top`
+--   Output looked like
+--     log info node 'X' 'a';
+--     @anchor(from: right, to: left)         -- noise: this is the default
+--     log info node 'X' 'b';
+--   producing verbose, non-author-friendly DESCRIBE output and noisy
+--   `mxcli diff-local` runs after a roundtrip.
+--
+-- After fix:
+--   `emitAnchorAnnotation` and `emitSplitAnchorAnnotation` (in
+--   cmd_microflows_show_helpers.go) suppress fragments that match the
+--   default and skip the entire annotation when all sides are defaults.
+--   Non-default sides (e.g. `to: top` on a return) are still emitted.
+--
+-- Usage:
+--   mxcli exec mdl-examples/bug-tests/320-describer-suppress-default-anchor-fragments.mdl -p app.mpr
+--
+--   mxcli -p app.mpr -c "describe microflow BugTest320.MF_LinearDefaults"
+--   The output must contain NO `@anchor` line — every flow uses defaults.
+--
+--   mxcli -p app.mpr -c "describe microflow BugTest320.MF_NonDefaultReturn"
+--   The output must keep `@anchor(to: top)` on the return statement.
+-- ============================================================================
+
+create module BugTest320;
+
+-- Linear flow, all defaults — describe must emit zero @anchor lines.
+create microflow BugTest320.MF_LinearDefaults ()
+begin
+  log info node 'BugTest320' 'a';
+  log info node 'BugTest320' 'b';
+  log info node 'BugTest320' 'c';
+end;
+/
+
+-- One non-default `to: top` on the return — describe must keep that fragment.
+create microflow BugTest320.MF_NonDefaultReturn (
+  $value: integer
+)
+returns boolean as $ok
+begin
+  log info node 'BugTest320' 'check';
+  @anchor(to: top)
+  return $value > 0;
+end;
+/

mdl-examples/bug-tests/322-multiline-source-expression-whitespace.mdl

@@ -0,0 +1,61 @@
+-- ============================================================================
+-- Bug #322: Multiline source expression whitespace lost on roundtrip
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   The visitor rebuilt expression strings from parsed expression nodes,
+--   so original line breaks and whitespace inside DECLARE initial values
+--   and LOG template parameters were normalized away. A multiline
+--   `declare $X string = ...` statement that authors had carefully
+--   formatted across several lines came back as a single very long line
+--   after describe → exec → describe. Inter-parameter blank lines in
+--   `LOG ... WITH (...)` were similarly collapsed, making real-world
+--   microflows non-fixpoint and producing noisy `mxcli diff-local` output.
+--
+-- After fix:
+--   Added a `SourceExpr` AST node that wraps an expression with its
+--   original source text. The visitor uses `buildSourceExpression` for
+--   source-sensitive declare/log/while expressions, and the executor
+--   serializes `SourceExpr` through to MDL output so the original
+--   whitespace and line breaks survive every roundtrip.
+--
+-- Usage:
+--   mxcli exec mdl-examples/bug-tests/322-multiline-source-expression-whitespace.mdl -p app.mpr
+--   mxcli -p app.mpr -c "describe microflow BugTest322.MF_MultilineDeclare"
+--   mxcli -p app.mpr -c "describe microflow BugTest322.MF_MultilineLogTemplate"
+--   The describe outputs must keep the multiline shape and must be
+--   fixpoints under describe → exec → describe.
+-- ============================================================================
+
+create module BugTest322;
+
+-- DECLARE initial value spread across several lines with leading `+`. The
+-- describer must preserve the line breaks rather than collapse them onto
+-- one line.
+create microflow BugTest322.MF_MultilineDeclare (
+  $Page: integer,
+  $Token: string
+)
+returns string as $Endpoint
+begin
+  declare $Endpoint string = '/api/v1'
++ '/items?page=' + toString($Page)
++ '&token=' + $Token;
+
+  return $Endpoint;
+end;
+/
+
+-- LOG template parameters separated by a blank line. The newline-only
+-- whitespace between `{1} = toString($Count)` and the next parameter must
+-- survive the roundtrip.
+create microflow BugTest322.MF_MultilineLogTemplate (
+  $Count: integer,
+  $Endpoint: string
+)
+begin
+  log info node 'BugTest322' 'Processed {1} items for {2}' with ({1} = toString($Count)
+
+, {2} = $Endpoint);
+end;
+/

mdl-examples/bug-tests/326-describer-pair-split-with-nearest-merge.mdl

@@ -0,0 +1,55 @@
+-- ============================================================================
+-- Bug #326: Describer paired splits with downstream merge instead of nearest
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   When a microflow had two sequential `if ... end if;` blocks, the
+--   describer could pair the FIRST split with the SECOND merge, nesting
+--   the continuation between the two ifs (and even the second if) inside
+--   the first if's body. A describe → exec → describe cycle then mutated
+--   the structure even though the original graph was valid:
+--     -- before fix, after first describe:
+--     if $Logo != empty then
+--       log info node 'App' 'logo';
+--       log info node 'App' 'after logo';   -- wrong: was outside first if
+--       if $Cover != empty then              -- wrong: was sibling, not nested
+--         log info node 'App' 'cover';
+--       end if;
+--     end if;
+--
+-- Root cause:
+--   Split/merge pairing picked any common downstream merge reachable from
+--   both branches, not the nearest one. Error-handler flows were included
+--   in the search, biasing it further.
+--
+-- After fix:
+--   `findMergeForSplit` now uses shortest-path distances per branch and
+--   selects the nearest common merge, ignoring error-handler flows for
+--   structural pairing.
+--
+-- Usage:
+--   mxcli exec mdl-examples/bug-tests/326-describer-pair-split-with-nearest-merge.mdl -p app.mpr
+--   mxcli -p app.mpr -c "describe microflow BugTest326.MF_SequentialIfs"
+--   The describe output must keep the two `if ... end if;` blocks as
+--   siblings (with the `log` between them at top level), and the
+--   describe → exec → describe cycle must be a fixpoint.
+-- ============================================================================
+
+create module BugTest326;
+
+create microflow BugTest326.MF_SequentialIfs (
+  $Logo: string,
+  $Cover: string
+)
+begin
+  if $Logo != empty then
+    log info node 'BugTest326' 'logo';
+  end if;
+
+  log info node 'BugTest326' 'after logo';
+
+  if $Cover != empty then
+    log info node 'BugTest326' 'cover';
+  end if;
+end;
+/