run --local: tee the Mendix runtime log to a file for debugging#38
Merged
Conversation
Findings #25: the warm loop prints its own progress but the Mendix runtime's own stdout/stderr — server stack traces and microflow LOG output — went only to an in-memory buffer surfaced solely on a startup failure. So when a page action threw, the browser showed the generic error dialog with nothing to correlate against, and a server-side bug couldn't be told apart from a client one. Tee the runtime JVM's stdout+stderr to <projectDir>/.mxcli/runtime.log via io.MultiWriter(buffer, file): the in-memory buffer still backs startup-error reporting, and the file makes the running app debuggable (tail -f). Appended across restarts with a "=== runtime start … ===" marker; the handle is closed on Stop and reopened on restart. On by default; --runtime-log <path> relocates it and "-" disables it. The path is printed at boot. Adds TestOpenRuntimeLog and run/run-local docs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sudoku-app finding #25:
mxcli run --localswallows the Mendix runtime log.The warm loop prints its own progress (build, reload, hub), but the runtime's own stdout/stderr — server stack traces and your microflow
LOG ERROR/LOG INFOoutput — went only into an in-memorysyncBufferthat is surfaced solely on a startup failure. During normal operation it landed nowhere on disk. So when a page action threw, the browser showed the generic Mendix error dialog with nothing to correlate it against, and a server-side bug couldn't be distinguished from a client one. (In the report, an "error selecting a cell" cost real time — the whole server side had to be excluded by driving the UI and querying Postgres directly before it turned out client-side.)Fix (the finding's own ask)
Tee the runtime JVM's stdout+stderr to
<projectDir>/.mxcli/runtime.logwithio.MultiWriter(buffer, file)— the in-memory buffer still backs startup-error reporting, and the file makes the running app debuggable (tail -f .mxcli/runtime.log).=== runtime start … ===; the handle is closed onStopand reopened on restart (no leak).--runtime-log <path>relocates it,--runtime-log -disables it.Runtime log: …)..mxcli/is already excluded from the--watchsignal, so the log never re-triggers a rebuild.Tests & docs
TestOpenRuntimeLog— verifies dir creation, the start marker, append-across-restart (2 markers), and that the prior handle is closed on reopen.runcommand help,run-localskill + docs-site page gain a "Debugging a server-side error" note and the flag.(The unrelated
TestServeIntegrationfailure in this package is an environment version mismatch — test app 11.6.3 vs local MxBuild 11.12.1 — not affected by this change.)🤖 Generated with Claude Code
Generated by Claude Code