From 7916efeb771e9ad3207c6f07b0cf842d5047d4c9 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 14 Oct 2026 14:01:28 +0000 Subject: [PATCH 1/2] log(bug-logs): upstream draft for run --watch theme rebuild dropping dist/pages (#284) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Paste-ready mendixlabs/mxcli draft, status DRAFT — NOT FILED: a theme-only rebuild under `mxcli run --local --watch` deletes deployment/web/dist/pages and still reports a successful reload; the other change classes watch serves stale; the timing table from #284; and the upstream questions (why a restart is ~5x a reload, whether a recreated microflow keeps its old compiled version). Evidence only from #284 and its 2026-10-14 comment. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw --- CHANGELOG.md | 1 + .../watch-theme-rebuild-drops-dist-pages.md | 73 +++++++++++++++++++ 2 files changed, 74 insertions(+) create mode 100644 bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md diff --git a/CHANGELOG.md b/CHANGELOG.md index ff60ea83..724418b6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -19,6 +19,7 @@ Sections dated before 2026-09-19 predate the cycle and stay as they are. Named m ## Unreleased +- log(bug-logs): **upstream draft for `mxcli run --local --watch`: a theme-only rebuild deletes `dist/pages` and still reports a successful reload** ([#284](https://github.com/MendixMau/mxcli-project-toolkit/issues/284)). `bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md`, status DRAFT — NOT FILED: the repro (one SCSS edit, every page 404s on `dist/pages/.js`, a restart restores all 135 bundles; twice in one app on mxcli v0.26.0 / Mendix 11.15.0), the other change classes watch serves stale, the timing table (reload 35 builds median 3.8 s, restart 44 builds median 19.2 s, max 55.2 s, 928 s total) and the upstream questions: why a restart is about 5× a reload, and whether a recreated microflow keeps its old compiled version by name. The toolkit side is already on master (exec.sh restart verdicts, `app-restart.sh`, ui-loop.md "What watch picks up"). Field evidence: the 2026-10-12 three-app UX run and its 2026-10-14 recurrence, as recorded in #284. — field retro #284, MendixMau - process(build): **Stage 5 drafts the ready set in parallel and applies serially.** The runbook dispatch row said "sequential within a module", which serialised drafting even for independent scripts; it now points to `iterative-build-loop.md` → Gate cost, the single statement of the rule. The unit is the build-plan row: every `BUILD` row whose "Depends on" rows are all applied, minus overlapping writers (two rows that replace, alter or drop+create the same document never share a ready set, and no row is drafted while it overlaps a queued unapplied one; `brd-to-build-plan.md` has Produces name every document a row writes), runs at once, its scripts in order, one `mdl-agent` per script. Applies stay one at a time through `bin/exec.sh`, and the ready set is recomputed after each. A queued draft made before a sibling apply landed is re-checked with `mxcli diff --format struct` (preflight STOP rule 23); any removal line (checked against `describe` per BUG-146) or STOP rule 21 target means re-draft, never patch, because a stale restatement of a shared document is exactly rule 21's silent seed-call loss and passes `check --references`. Report `ready set N, drafted N, applied k`; the `mdl-agent` template says a drafter never applies and never depends on an unapplied draft. Field evidence: none yet. — MendixMau - fix(platform-link): **CLI commits now show their changed documents in Studio Pro History.** Studio Pro's History → Model changes pane reads a `ModelChanges` array from the commit's `refs/notes/mx_metadata` note. Trap 6c's hand-written template set it to `[]`, so every mxcli/agent commit showed "Model changes 0" (field project: 270 of 270 notes empty). New `project-bin/mx-metadata-note.py` (stdlib only) computes the array from the commit's changed `.mxunit` files, in Studio Pro's entry shape: Status, UnitID, UnitType, UnitName and Module (walked up the `.mpr` Unit tree). It has `changes` / `write` / `backfill` / `sync ` subcommands. `install-project-hooks.sh` now also installs post-commit and post-rewrite hooks that write the note and never block, and `--check` covers them, so `sync-project.sh` rolls them out to wired projects. Notes are published with `mx-metadata-note.py sync ` after the branch push. Push config is never touched. With mxcli v0.26+ in the project root the hooks call `mxcli git note --write` instead (mendixlabs/mxcli#1337); the Python script is the fallback for older pins, and on 160 field commits both wrote the same 3,594 entries. Trap 6c rewritten. Measured against Studio Pro's own notes, 51 commits in 5 apps: 3387/3389 entries exact on all five fields. Field run on a 357-commit Mendix 11.15.0 app: 158 notes backfilled and pushed, and Studio Pro History lists the documents per revision. Review fixes: an earlier revision added `HEAD` + the notes ref to `remote..push`. It was dropped because any push refspec replaces `push.default`. A branch tracking a differently named upstream got a new same-named branch on Team Server where `simple` refuses, a missing local notes ref failed the whole push, and nobody knows whether Studio Pro's own push reads that config. The installer now only fetches the remote's notes (non-forced). It removes that exact `HEAD` + notes pair if present, and leaves and reports any other entry. `sync` handles a remote with no notes ref (it used to exit 1) and retries a rejected push once after re-merging. A note that already lists changes (Studio Pro's) is never overwritten by `write`/`backfill` without `--force`, and `sync` keeps a colleague's non-empty note over ours. The mxcli probe greps `git note --help` for `--write`. Hooks and docs call the script through `resolve_py`. Fixture `tests/wave2/test-mx-metadata-note.sh` (40 cases, over real captured template units; single- and two-tree layouts, amend, backfill and `--force`, push exit codes identical to a no-hooks clone, leftover-refspec cleanup, sync to an empty remote and its retry, notes fetch at install, a diverged notes merge; green under `init.defaultBranch` master and main). — field project (Mendix 11.15 app), MendixMau - learn(fixture-seeding): **explore the data structure first, choose rows by use case, scan actions for resets before any run.** Two seeding runs on public template apps: seeding raised journey passes 33 -> 58 and 20 -> 51 of the same sets (FAIL 93 -> 68, 163 -> 132; INVALID unchanged), and a "Reset all demodata" journey wiped accounts so 104 of 127 journeys reported `The username or password you entered is incorrect`, identical on empty and seeded databases. Skill gains three questions a seed must answer, a use-case checklist, a destructive-action scan, a generic traps table with symptoms, measured expectations and a denominator checklist; routing trigger now fires on seed/test/demo data and empty pages. Independent review fixes: object ids follow the Mendix bigint pattern with a business-key guard (no uuids), associations are seeded where the page's path stores them, four new traps (enum names, inheritance chain, calculated attributes, view/external entities), and the port-offset and container-label traps moved to `harness-architecture.md`. — MendixMau diff --git a/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md b/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md new file mode 100644 index 00000000..0ae9a802 --- /dev/null +++ b/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md @@ -0,0 +1,73 @@ +Repo: mendixlabs/mxcli +Source: toolkit issue #284 (field retro 2026-10-12, three apps under `mxcli run --local --watch`) and its 2026-10-14 recurrence comment; related toolkit issues #275, #282, #285, #337 +Status: **DRAFT — NOT FILED**. Not retested on a neutral app yet, and no duplicate search of mendixlabs/mxcli done: do both before filing. Every number below comes from the field run's watch output and runtime logs as recorded in #284; nothing was re-measured for this draft. + +--- everything above this line is stripped before filing --- + +**Title:** `run --local --watch`: a theme-only rebuild deletes `dist/pages` and reports a successful reload + +## Environment + +- mxcli **v0.26.0** +- Mendix **11.15.0** +- `mxcli run --local --watch`, one app per localhost port, three apps in one field run + +## Bug: a theme-only rebuild deletes the page bundles + +1. Start an app with `mxcli run --local --watch` and open any page. +2. Edit any `theme/web/*.scss` file. +3. Watch prints "Change detected, rebuilding", and the reload reports success. +4. `deployment/web/dist/pages/` is now gone. Only `chunks/` and `index.js` remain. +5. Every page fails in the browser with + `Failed to fetch dynamically imported module ... dist/pages/.js` + (a 404 in the runtime log). The user sees "An error occurred". + +Reproduced on two consecutive theme-only builds in one app (2026-10-14). A full restart of +`mxcli run` restored all 135 page bundles every time. The same symptom appeared in the first run +(2026-10-12): one SCSS edit dropped the `deployment/web/pages` bundles (404s), and another left a +grid column at 24 px instead of the stored 120/240 until a restart. + +**Expected:** a theme-only rebuild either regenerates `dist/pages`, or prints "restart needed" +instead of reporting a successful reload. + +**Cost beyond the 404s:** the only fix is a restart, and each restart signs every user out. One +app's runtime log shows 7 starts in about 90 minutes of theme work. + +## Other changes watch does not apply + +In the same run, these edits were not picked up while the app was already running. The app kept +serving the old model, and nothing in the watch output said so: + +- a microflow dropped and recreated (the old version kept serving); +- a new microflow grant; +- a new attribute, stored or calculated; +- a `Url` added to an existing page (the route table predates it; the deep link lands on Home); +- a new page. + +While stale, the app showed symptoms that look like real defects: security errors on pages, a +`NoClassDefFoundError` for a widget class, and a picker error. Each cost a diagnosis round before +anyone suspected a stale runtime. 16 task-ledger lines carry a needs-restart status, roughly 26 +restarts across the three apps. + +## Timings (watch output, 79 build lines, one night, three apps) + +| Build class | Builds | Median | Max | Total | +|---|---|---|---|---| +| reload | 35 | 3.8 s | 8.3 s | not recorded | +| restart | 44 | 19.2 s | 55.2 s | 928 s | + +Also in the same night: 39 cold starts of the run command. + +## Questions + +1. Which change classes need a restart and which a reload? Can watch detect the restart classes + and print "restart needed" (or restart by itself) instead of serving stale code? +2. Why is a restart-class build about 5× a reload (median 19.2 s against 3.8 s)? +3. After a microflow is dropped and recreated, does the runtime keep serving the old compiled + version by name? What would make watch pick up the new one? + +## Workaround in use + +Stop the app, edit the theme, start it again. For the other classes, restart the app after the +edit. The restart itself is cheap once someone knows it is needed; the expensive part is telling +a stale runtime from a real defect. From 0b9b931b26f84568c1ea317939b40929f0a23f27 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 14 Oct 2026 14:03:27 +0000 Subject: [PATCH 2/2] log(bug-logs): #284 draft states only what the issue says about stale edits Review of #363: "nothing in the watch output said so" was an inference not in #284; replaced with the issue's own wording (the implementer saw the old behaviour until the app was restarted). Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw --- .../watch-theme-rebuild-drops-dist-pages.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md b/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md index 0ae9a802..ea80d6dc 100644 --- a/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md +++ b/bug-logs/pending-github-issues/watch-theme-rebuild-drops-dist-pages.md @@ -35,8 +35,8 @@ app's runtime log shows 7 starts in about 90 minutes of theme work. ## Other changes watch does not apply -In the same run, these edits were not picked up while the app was already running. The app kept -serving the old model, and nothing in the watch output said so: +In the same run, these edits were not picked up while the app was already running. The +implementer saw the old behaviour until the app was restarted: - a microflow dropped and recreated (the old version kept serving); - a new microflow grant;