Skip to content

Fix the nightly's Mendix 10.24 leg: two independent version-gating defects - #1110

Merged
ako merged 2 commits into
mainfrom
fix/nightly-mx10-workflow-tests
Sep 16, 2026
Merged

ako merged 2 commits into
mainfrom
fix/nightly-mx10-workflow-tests

Conversation

@ako

@ako ako commented Sep 16, 2026

Copy link
Copy Markdown
Collaborator

The nightly (run 35067847232) has been red since 09-15. Only the Mendix 10.24 leg fails — all five 11.x legs pass — so nothing here is a product regression. mxcli's version gating is working correctly in both cases; the tests assumed Mendix 11.

Two independent causes, one commit each.

1. Four workflow round-trips (red since 09-15)

roundtrip_workflow_test.go:99: create page RoundtripTest.SubPage:
  create page with parameters requires Mendix 11.0.0+ (project is 10.24.24.119349)

db61b949 gave the task pages Params: { $WorkflowUserTask: ... }, because exec now checks a user task's page signature and a parameterless page is CE7410 on 11.13. That fix was right — and it is mutually exclusive with Mendix 10: a valid task page needs a parameter, and CREATE PAGE cannot write one below 11.0 (#294). These fixtures cannot exist on Mendix 10, so the tests must skip there.

The gate goes inside createTaskPages, not at the four call sites, so a fifth caller cannot forget it.

Timing confirms the attribution: db61b949 landed 09-14 18:10 UTC, after that day's nightlies (07:36, 07:38 — both green); the next one, 09-15 07:19, failed with exactly these four.

2. The doctype script (new in the 09-16 run)

skipped 531 version-gated lines
Execution error: entity 'WFTest.OrderContext' not found for parameter 'OrderContext'
mx check passed: 0 errors

Different mechanism. filterByVersion treats each -- @version: directive as replacing the previous one, so any resets the constraint to nil. 24-workflow-examples.mdl opens at line 1 with 11.0+, creates WFTest.OrderContext and WFTest.TaskPage under it (the page takes a parameter, so 11.0+ only), then marks PART H any while using both. On Mendix 10 the fixtures were skipped and PART H ran anyway against a project without them. The model that did get built was valid — hence mx check 0 errors, with only the execution error failing the test.

A directive appearing before any statement is now the file's floor, and later directives narrow it rather than replace it. Precisely scoped: 24-workflow-examples.mdl is the only fixture with a line-1 directive; the other six use any mid-file to close a gated section, where there is no baseline and nothing changes. A test pins that second case so the fix cannot over-fire.

Introduced by 898e78eb (PART H), merged via #1107 — which is why this appears in the 09-16 run and not 09-15. Verified: the 09-15 run shows only the four page failures.

Verification — on the version that actually failed

I downloaded mxbuild 10.24.24.119349 and ran the real leg locally rather than reasoning about it.

Mendix 10.24 Mendix 11.12
four workflow tests SKIP (were FAIL) PASS — still run
24-workflow-examples.mdl PASS, 531 lines skipped PASS, 15 skipped, PART H runs
whole doctype suite ok ok
whole mdl/executor integration package ok, 0 failures, 205s ok, 0 failures, 198s

Control on the harness fix: stubbing it back out fails TestFilterByVersion_FileBaselineSurvivesAny with the reported symptom.

Note on scope

Two commits, two causes, one symptom (a red nightly). Happy to split into two PRs if you'd rather they land separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BNDe35kDNsMX5cz4Ahn4rk

ako and others added 2 commits September 16, 2026 08:09
The nightly's Mendix 10.24 leg has failed since 2026-09-15 with four
workflow round-trips dying in their fixture:

  create page RoundtripTest.ReviewPage: create page with parameters
  requires Mendix 11.0.0+ (project is 10.24.24.119349)

db61b94 gave the task pages `Params: { $WorkflowUserTask: ... }` because
exec now checks a user task's page signature and a parameterless page is
CE7410 on 11.13. That fix is right, and it is mutually exclusive with
Mendix 10: a valid task page NEEDS a parameter and CREATE PAGE cannot write
one below 11.0 (#294). So these fixtures cannot exist on
Mendix 10 and the tests have to skip there.

The gate goes in createTaskPages rather than at the four call sites, so a
fifth caller cannot forget it -- the constraint belongs to the fixture, not
to the tests that happen to use it.

db61b94's own message says it was "verified locally on both engines with a
real 11.13 project". 11.13 only; 10.24 is the leg that broke. Measured now
on both: with mxbuild 10.24.24.119349 all four SKIP ("Requires Mendix
11.0+"), and on 11.12.0 all four still RUN and PASS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BNDe35kDNsMX5cz4Ahn4rk
…: any`

The second half of the nightly's 10.24 failure, and a different defect:

  skipped 531 version-gated lines
  Execution error: entity 'WFTest.OrderContext' not found for parameter 'OrderContext'
  mx check passed: 0 errors

filterByVersion treats each directive as REPLACING the previous one, so
`-- @Version: any` resets the constraint to nil. 24-workflow-examples.mdl
opens at line 1 with `-- @Version: 11.0+`, creates WFTest.OrderContext and
WFTest.TaskPage under it (the page takes a parameter, so it is 11.0+ only),
and then marks PART H `any` while using both. On Mendix 10 the fixtures
were skipped and PART H ran anyway, against a project that did not have
them. The model that did get built was valid, which is why mx check passed
and only the execution error failed the test.

A directive appearing before any statement is now the FILE's floor and
later directives narrow it instead of replacing it. That is what `any`
plainly means there -- "no constraint beyond this file's" -- and it is
precisely scoped: 24-workflow-examples.mdl is the only fixture with a
line-1 directive. The other six use `any` mid-file to close a gated
section, where there is no baseline and nothing changes.

Two tests, and the second is the one that keeps this honest: a mid-file
`any` must still reopen for every version. Stubbing the fix back out fails
TestFilterByVersion_FileBaselineSurvivesAny with the reported symptom.

Measured end to end with mxbuild 10.24.24.119349: the file goes from
Execution error to PASS, skipped lines 487 -> 531 (PART H now gated too),
mx check 0 errors. On 11.12.0 only 15 lines are skipped, PART H still runs,
mx check 0 errors. The whole doctype suite passes on both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BNDe35kDNsMX5cz4Ahn4rk
@github-actions

Copy link
Copy Markdown

AI Code Review

What Looks Good

  • The PR correctly identifies and fixes two independent version-gating defects causing the Mendix 10.24 nightly failures.
  • The fixes are minimal, scoped, and well-documented with clear comments explaining the rationale.
  • New test file version_filter_baseline_test.go adds necessary integration test coverage for the version filtering logic, including:
    • A baseline test ensuring file-level -- @version: directives act as a floor (not reset by later any)
    • A control test verifying mid-file any directives still reopen sections on all versions
  • The workflow test fix properly gates the fixture creation at the source (createTaskPages helper) to prevent omission at call sites.
  • Local verification on Mendix 10.24.24.119349 confirms both fixes resolve the failures without affecting 11.x legs.
  • No new MDL syntax or features are introduced, so syntax design and full-stack consistency checkls are not applicable.
  • Changes obey scope and atomicity: each addresses one specific issue (workflow fixture gating, version filter baseline handling).

Recommendation

Approve the PR. It is ready to be merged.


Automated review via OpenRouter (Nemotron Super 120B) — workflow source

@ako
ako merged commit ea9fa37 into main Sep 16, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant