Skip to content

fix(tests): version-gate the parameter page in alter-page-insert-into doctype#10

Merged
ako merged 1 commit into
mainfrom
claude/mxbuild-diagnostics-spike-emta6h
Jul 22, 2026
Merged

fix(tests): version-gate the parameter page in alter-page-insert-into doctype#10
ako merged 1 commit into
mainfrom
claude/mxbuild-diagnostics-spike-emta6h

Conversation

@ako

@ako ako commented Jul 22, 2026

Copy link
Copy Markdown
Owner

Summary

The nightly integration run fails on TestMxCheck_DoctypeScripts/alter-page-insert-into (both engines):

Execution error: create page with parameters requires Mendix 11.0.0+ (project is 10.24.19.104498)

The nightly builds its shared source project with Mendix 10.24.19, but alter-page-insert-into.mdl created AlterInto.Detail with params: { $Item: AlterInto.Item } — a page parameter, which requires Mendix 11.0+. On 10.x the executor correctly refuses, so the script errors during execution (the mx check passed: 0 errors line afterward is unrelated — the failure is the execution error, not the check).

Fix

Move the AlterInto.Detail page and its ALTER (the dataview-child INSERT INTO case) to the end of the script, contiguous, under a single -- @version: 11.0+ gate. The harness's filterByVersion blanks that section on a sub-11 project. The two AlterInto.Home cases (fill an empty container; append to a populated one) stay ungated, so INSERT INTO is still exercised on 10.x — only the parameter-dependent case is skipped there.

No production code change — a doctype example script only.

Testing

Ran the subtest against both cached mxbuild versions through the integration harness (-tags integration):

  • 10.24.19 (reproduces the nightly, forced via a reference/mxbuild symlink): both engines PASSMendix 10.24.19: skipped 9 version-gated lines, mx check 0 errors.
  • 11.12.1: both engines PASS — full script runs (no lines skipped), mx check 0 errors.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4


Generated by Claude Code

… doctype

The nightly builds its shared source project with Mendix 10.24.19, but
alter-page-insert-into.mdl created AlterInto.Detail with `params: {...}` — a
page parameter, which requires Mendix 11.0.0+. On 10.x the executor rightly
refused ("create page with parameters requires Mendix 11.0.0+"), failing the
TestMxCheck_DoctypeScripts/alter-page-insert-into subtests on both engines.

Move the Detail page and its ALTER (the dataview-child INSERT INTO case) to the
end of the script, contiguous, under a single `-- @Version: 11.0+` gate so the
harness filters them out on 10.x. The two AlterInto.Home cases (fill an empty
container; append to a populated one) remain ungated, so INSERT INTO is still
exercised on 10.x.

Verified against both cached mxbuild versions via the integration harness:
- 10.24.19: both engines PASS, "skipped 9 version-gated lines", mx check 0 errors.
- 11.12.1: both engines PASS, full script runs, mx check 0 errors.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
@ako
ako merged commit 60c233f into main Jul 22, 2026
3 checks passed
ako pushed a commit that referenced this pull request Jul 27, 2026
…ltiline-string hint

Three separate authoring papercuts from the RSS-reader build:

- #10 The CLAUDE.md/AGENTS.md template that `mxcli init` writes into every
  project contradicted the shipped skills: it listed `DECLARE $Entity
  Module.Entity;` and `DECLARE $List List of ... = empty;` as supported
  (both are rejected — MDL043/CE0053 and MDL040) and listed `CASE … END
  CASE` as NOT supported (it IS — the enum split). Move the two DECLARE
  forms to the NOT-supported table with the correct "use a parameter /
  retrieve / create" guidance, and list CASE as supported.

- #12 write-microflows.md documented the `$latestHttpResponse` body
  attribute as lowercase `content`; the real name is `Content` (inherited
  from System.HttpMessage, so DESCRIBE ENTITY System.HttpResponse doesn't
  list it). Lowercase fails CE0117. Fix both mentions and note why.

- #6 A string literal that runs off the end of its line got the
  "unescaped apostrophe — double your apostrophes" hint, which only makes
  it worse. Detect a newline inside the token-recognition-error payload
  and emit a distinct "string literals cannot span multiple lines" hint
  instead. The single-line apostrophe heuristic is unchanged.

Reported from the RSS-reader build (findings #10, #12, #6).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
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.

2 participants