Skip to content

[Bug] ALTER PAGE SET Title / SET Label silently succeeds but change does not persist #292

Open
Open
[Bug] ALTER PAGE SET Title / SET Label silently succeeds but change does not persist#292

Description

@Chendodelangen
Chendodelangen
opened on Apr 24, 2026

Summary

ALTER PAGE SET Title and SET Label (on input widgets) return Altered page but the change is not saved. The next DESCRIBE PAGE still shows the original value.

Environment

  • mxcli version: current
  • Mendix version: 10.24.15

Steps to Reproduce

# Set page title
./mxcli -p MyProject.mpr -c "ALTER PAGE Mod.MyPage { SET Title = 'New title' };"
# Output: Altered page Mod.MyPage  ← appears successful

# Verify
./mxcli -p MyProject.mpr -c "DESCRIBE PAGE Mod.MyPage"
# Output still shows: Title: 'Old title'

# Same behaviour for widget labels
./mxcli -p MyProject.mpr -c "ALTER PAGE Mod.MyPage { SET Label = 'New label' ON textBox1 };"
# Output: Altered page Mod.MyPage
# DESCRIBE still shows: Label: 'Old label'

Expected Behaviour

The title / label is updated in the model, or mxcli returns an error explaining why it cannot be changed.

Actual Behaviour

The operation reports success but the model is unchanged. No error, no warning.

Root Cause (suspected)

Mendix stores page titles and widget labels as TranslatableString internally. mxcli likely writes to a slot that does not match the language-specific storage format, so the value is discarded on serialisation.

Workaround

Edit the title or label manually in Studio Pro.

Severity

Medium — silent failure is misleading; the change appears to have been applied but wasn't.

Activity

  1. github-actions commented on Apr 24, 2026

    @github-actions
    github-actionsBot
    on Apr 24, 2026 – with GitHub Actions

    Issue Triage

    Summary:
    The ALTER PAGE SET Title and SET Label commands report success but do not persist the changes in the .mpr file.

    Checklist for bug report completeness

    Required info Present? Details
    mxcli version (exact output of mxcli --version or commit/build) ❌ Only “current” is given; need the exact version string.
    Mendix version of the project ✅ 10.24.15
    Scenario (what the user was trying to do) ✅ CLI commands to alter page title and widget label, with commands shown.
    Expected output ✅ Title/label should be updated (or an error should be returned).
    Experienced output ✅ Command reports “Altered page …” but DESCRIBE PAGE shows the original value; no error/warning.
    AI bug report (output of mxcli diag --bundle or session log) ❌ Not provided.

    What’s missing:

    • The precise mxcli --version output (or commit/build identifier).
    • The diagnostic bundle or session log from mxcli diag --bundle to help investigate the internal state.

    Could you please add those details? Once we have the exact mxcli version and the diagnostic information, we’ll be able to look into why the changes aren’t being saved. Thank you for reporting this issue!

    Automated triage via OpenRouter — workflow source

  2. Chendodelangen commented on Apr 24, 2026

    @Chendodelangen
    Chendodelangen
    on Apr 24, 2026
    Author

    Additional information requested by the triage bot:

    mxcli version:

    v0.7.0-dirty (2026-04-21T08:30:06Z)
Go: go1.26.2 windows/amd64

    Diagnostic log entries (from session on 2026-04-24):

    The following entries confirm the silent success behaviour. Both SET Title and SET Label commands returned INFO-level execute events (i.e. reported success) but the subsequent DESCRIBE PAGE showed no change persisted:

    {"time":"2026-04-24T10:30:25.6432573+02:00","level":"INFO","msg":"session_start","version":"v0.7.0-dirty","mode":"batch","args":["mxcli.exe","-p","AssetManagement.mpr","-c","ALTER PAGE AuditTrail_Custom.AuditTrail_Asset_ReasonForChange { SET Title = 'Reason for change (optional)'; SET Label = 'Reason for change (optional, max 120 characters)' ON textBox1 };"],"pid":12532}
{"time":"2026-04-24T10:30:26.0064861+02:00","level":"INFO","msg":"execute","stmt_type":"AlterPageStmt","stmt_summary":"ALTER PAGE AuditTrail_Custom.AuditTrail_Asset_ReasonForChange","duration_ms":730}
{"time":"2026-04-24T10:30:56.0336423+02:00","level":"INFO","msg":"session_start","version":"v0.7.0-dirty","mode":"batch","args":["mxcli.exe","-p","AssetManagement.mpr","-c","ALTER PAGE AuditTrail_Custom.AuditTrail_Asset_ReasonForChange { SET Label = 'Reason for change (optional, max 120 chars)' ON textBox1 };"],"pid":19080}
{"time":"2026-04-24T10:30:56.7762495+02:00","level":"INFO","msg":"execute","stmt_type":"AlterPageStmt","stmt_summary":"ALTER PAGE AuditTrail_Custom.AuditTrail_Asset_ReasonForChange","duration_ms":733}

    No execute_error entry was emitted for either command. The DESCRIBE PAGE after each attempt still showed the original title and label text, confirming the change was silently discarded.

    A full diagnostic bundle (mxcli-diag-20260424-110448.tar.gz) is available and can be shared if needed.

  3. ako
    added a commit that references this issue on Aug 26, 2026

    Merge pull request #292 from ako/claude/mendix-default-styling-1fgvpm

    dbc90dc

  4. MendixMau commented on Sep 8, 2026

    @MendixMau
    MendixMau
    on Sep 8, 2026
    Contributor

    Still reproducing on mxcli v0.20.0 / Mendix 11.13.0, and the silent-discard half of this is costing more than the report suggests — so here is a second, independent reproduction with impact evidence.

    Summary

    alter page … { set Label = '…' on <widget> } reports success, passes mxbuild, and does not
    change the model    . DESCRIBE PAGE afterwards shows the old label.

    This is a silent no-op, not an unsupported property: the setter resolves the widget and knows its
    property list — it rejects Caption by name on the same widget — and it applies Class on
    that same widget correctly. It accepts Label, reports success, and drops the value.

    Environment

    • mxcli v0.20.0
    • Mendix 11.13.0
    • Linux container

    Repro

    One page, one session, four statements on a throwaway copy of the .mpr:

    set Label   = 'Indicator status *' on cb100Ind    (combobox) → "Altered page", model unchanged
set Label   = 'PROBE-TEXTBOX'      on tb010Phase  (textbox)  → "Altered page", model unchanged
set Class   = 'probe-class'        on cb100Ind               → applied correctly
set Caption = 'PROBE-CAPTION'      on cb100Ind               → Error: failed to set:
                                                               failed to set Caption on cb100Ind:
                                                               widget has no Caption property

    Verified after each statement with
    mxcli -p copy.mpr -c "DESCRIBE PAGE Approval.Approval_StationTask".

    Impact

    Every gate in the pipeline passes on an inert script. mxcli check --references passes, exec
    prints Altered page, mxbuild returns 0 errors, the commit goes in, and the model is unchanged.
    The only way to find out is to open the page in a browser and read it.

    On this project the affected script existed solely to add a required-field marker to a label. It
    was committed, gated and reported as done, and the marker was never there. A reviewer trusting the
    exec output — which is the normal thing to do — would not look. This is materially worse than
    BUG-122, where the equivalent ALTER PAGE property mismatch at least fails loudly.

    Workaround

    alter page Module.Page {
  replace <widget> with { <widget re-declared with the new label> }
}

    Applies correctly. Every other property must be re-declared verbatim from DESCRIBE PAGE or the
    replace quietly drops it — so a one-word label change becomes a hand-transcribed widget block.

    Expected

    Apply Label, or reject it the way Caption is rejected. A write path that reports success
    without writing is the one failure mode a validation pipeline cannot catch.

    Related

    BUG-122 (ALTER PAGE … SET PageSize rejected on a widget CREATE accepts). Same underlying theme
    — the ALTER PAGE property surface disagrees with the CREATE one — opposite and much more
    dangerous failure mode.

  5. ako commented on Oct 1, 2026

    @ako
    ako
    on Oct 1, 2026
    Collaborator

    Triage on main (016f784, 2026-10-01): partly fixed.

    On a TestApp copy (11.14), alter page T3.P { set Title = 'New title'; set Label = 'New label' on textBox1; set Caption = 'NewCap' on btnSave } printed 'Altered page T3.P'. Describe then shows Title: 'New title' and Caption: 'NewCap', but the textbox still has Label: 'Old label'. The same happens under mdl 0. Cause: setWidgetLabelMut (mdl/backend/pagemutator/mutator.go ~3080) returns nil without doing anything when the widget has no 'Label' doc.

    Still open: SET Label on input widgets is still a silent no-op that reports success. It needs to write to the right label storage or return an error.

    Keeping this open for the remaining part.

  6. ako
    added 2 commits that reference this issue on Oct 15, 2026

    fix(alter page): SET Label no longer reports success while storing no…

    286bd43

    test(bug-tests): write the #292 regression script in canonical MDL

    592d29b
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