Skip to content

a bare or double-quoted String literal in a CHANGE / FILTER expression passes check --references, writes, and fails mx check with CE0117 #1044

Description

@marclehane-creator

Eval row 17 (Change AND Filter, two errors) and row 33 (Change, fixed in-loop). Isolated on
probe/p3a-bare.mdl (Status = Open, Status = Closed) and probe/p3b-dquote.mdl
(Status = "Open", Status = "Closed"):

CREATE MICROFLOW Bench.Probe_BareLiteral ($Customer: Bench.Customer) RETURNS void BEGIN
  RETRIEVE $AllOrders FROM $Customer/Bench.Order_Customer;
  $OpenOrders = FILTER($AllOrders, Status = Open);
  LOOP $Order IN $OpenOrders BEGIN
    CHANGE $Order (Status = Closed);
    COMMIT $Order;
  END LOOP;
END;

Both pass rung 2 (0 errors, 0 warnings, 1 info — the MDL067 commit note) and both exec. Row 17's
compiler output for the same shapes: [CE0117] "Error(s) in expression." at Change object activity 'Change 'Order' (Status)' and … at List operation activity 'Filter'. In a Mendix expression
Open is an unresolvable identifier and "Open" is not a string literal; check already parses the
expression (Issue 80 proves it re-parses) and knows Status is a String attribute, so both are
detectable at rung 2 — or exec could quote a bare identifier that matches no variable/attribute
when the target attribute is a String, as Studio Pro's editor would refuse to save it.

Issues 81 and 82 — RETRACTION RETRACTED 2026-09-04 19:50Z: both REPRODUCE on a fresh copy; the earlier "NOT REPRODUCED" came from a BLIND probe copy

The 17:14Z/17:18Z notes above said Probe_LogObjectParam, Probe_BareLiteral and Probe_DoubleQuotedLiteral
compiled clean. They were compiled on the isolation probe, a fixture copy that had been exec'd about
fifteen times by then. At 19:48Z a control flow containing RETURN $X + $DoesNotExist; ALSO compiled clean
on that copy — and produced [CE0109] "Undefined variable 'DoesNotExist'." on a fresh copy. The copy had
stopped reporting MICROFLOW errors while still reporting PAGE errors (the CE1613s above are real). Cause
unknown; every microflow verdict from that copy is void.

Re-measured on a fresh copy (the isolation probe), four probes exec'd, ONE compile:

probe statement mx check
p2 LOG WARNING NODE 'Orders' 'Customer {1} has no open orders' WITH ({1} = $Customer) (object) [CE0117] "Error(s) in expression." at Log message activity 'Log message (warning)'
p9 LOG INFO NODE 'Archive' 'Archived {1} orders.' WITH ({1} = $Count) (Integer) [CE0117] … at Log message activity 'Log message (info)'
p3a FILTER($AllOrders, Status = Open) / CHANGE $Order (Status = Closed) [CE0117] … at List operation activity 'Filter' + … at Change object activity 'Change 'Order' (Status)'
p3b the same with "Open" / "Closed" (normalised to bare by the writer) the same two CE0117s

So Issue 81 is broader than written: the WITH ({1} = …) template-parameter form fails the compiler for
EVERY parameter type at 0.20.0 — the writer's template/parameter emission is wrong, not the caller's type.
Real app row 62 hit it live with an Integer ({1} = $Count) and, steered by a decision line that blamed
the type, DROPPED the count from the message to get to 0 errors. Issue 82 stands as written (bare and
double-quoted literals both pass check --references, both fail the compiler). Both are ready to file.

Method note for this register: a probe copy that has been written many times is not the fixture any
more. Every probe session from here starts on a fresh copy with a deliberately broken control of the
same unit type; exec counts on a copy are recorded with its verdicts.


mxcli 0.20.0, Mendix 11.12.x, Windows 11. Found while evaluating a self-hosted agent loop that drives check → check --references → exec → mx check; each item above was reproduced on a fresh copy of the fixture or app named.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions