fix(describe): emit workflow annotations as comments, not statements (mendixlabs/mxcli#1007) - #351
Merged
Merged
Conversation
DESCRIBE WORKFLOW emitted `annotation '<text>';` — the exact construct MDL-WF04 exists to refuse, and that execCreateWorkflow refuses again. So the describer produced output mxcli's own checker rejects: 13 MDL-WF04 errors from one unmodified describe of a 23-activity workflow. Two parts of the tree disagreed, each stating its position in a comment. The emitter: "emitted as a parseable MDL statement so it survives round-trips." The validator: it "produces a model Mendix cannot load (the annotation is placed in the activity flow, which accepts only flow elements)". The emitter's comment was the stale one. The reporter read these as canvas annotations. They are not: formatAnnotation is called at 10 sites, always with an activity's ATTACHED Annotation, and the describer converted attached to standalone — which is the refused form. That matters for the fix, because MDLWorkflow.g4 has only the standalone workflowAnnotationStmt: no MDL input can express an attached annotation, even though the write path stores one. Commenting it out therefore loses nothing that was reachable. Both emit paths become comments — the attached one and the standalone WorkflowAnnotationActivity read back from a model. The standalone branch also has to mark itself a comment, or the terminator logic appends `;`. The microflow domain already has an attached form (`@annotation 'text'`) that round-trips properly. Giving workflow activities the same prefix would preserve the annotation instead of commenting it out; that is a grammar change and deliberately not bundled here. Tests assert the emitted MDL parses, passes ValidateWorkflow, AND still contains the text — the last one because dropping the annotation entirely would satisfy the first two. Reported as mendixlabs#1007. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-describe-annotation-comments
…-annotation-comments
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
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.
Fixes
mendixlabs/mxcli#1007. Stacked on #348 (same function,formatAnnotation) — base isfix/workflow-describe-quote-doubling; retarget tomainonce that merges.DESCRIBE WORKFLOWemittedannotation '<text>';— the exact construct MDL-WF04 exists to refuse, and thatexecCreateWorkflowrefuses again. So the describer produced output mxcli's own checker rejects: 13 MDL-WF04 errors from one unmodified describe of a 23-activity workflow.Two parts of the tree disagreed, in comments
The emitter's comment was the stale one.
One correction to the issue's framing, and it changes the fix
The report reads these as canvas annotations. They aren't:
formatAnnotationis called at 10 sites, always with an activity's attachedAnnotation, and the describer converted attached → standalone, which is the refused form.That matters, because the issue's option 2 ("support writing annotations, relax MDL-WF04") needs a grammar change:
MDLWorkflow.g4has only the standaloneworkflowAnnotationStmt, so no MDL input can express an attached annotation today — even though the write path stores one (addActivityBaseFields). Commenting it out therefore loses nothing that was reachable, which is what makes option 1 honest rather than a concession.Worth knowing: the microflow domain already solved this
MDLMicroflow.g4has@annotation 'text'as an activity prefix and round-trips it properly. Giving workflow activities the same prefix is the non-lossy fix — the annotation would survive a rebuild instead of being commented out. That's a grammar change across every workflow activity rule, so it's a feature, deliberately not bundled here. Happy to open it as a follow-up.Two traps in the implementation
--comment runs to end of line, so a multi-line annotation must be prefixed per line, or the tail becomes stray tokens — the same failure the statement form had.isComment, or the terminator logic appends;to a comment line.Tests
Four, verified against the old emitter:
Each asserts the emitted MDL parses, passes
ValidateWorkflow, and still contains the text — the last because dropping the annotation entirely would satisfy the first two. The fourth test (NoAnnotationEmitsNoComment) passes both before and after, on purpose: it's the control that the change adds no stray comment lines.🤖 Generated with Claude Code