fix(rest): request bodies — correct what was silently wrong, add what was missing, refuse what cannot be written

[ako]

Three commits on REST request bodies, each measured against Studio Pro-authored microflows in ako/TestApp (Mendix 11.13.0) covering Custom, Mapping, FormData and Binary.

Every defect here shares a shape: the model stays valid, so nothing reports the loss. mxcli check passes, mx check reports 0 errors, the app builds and the request often returns 200 — and the payload is wrong or absent.

1. cbed3b0 — body: file sent the literal text $Doc

On a consumed REST operation, Body: file from $Doc was written as a Rest$StringBody holding the expression text. Measured against httpbingo with an 8090-byte PNG:

Content-Length: 4
data:application/octet-stream;base64,JERvYw==   ->  b'$Doc'

Both engines folded FILE into the TEMPLATE branch — consumed_rest_write.go (default) and writer_rest.go (legacy). describe rendered it back as Body: template '$Doc', so the round trip looked self-consistent.

There is no correct type to write: the metamodel has exactly three request-body types (Rest$JsonBody, Rest$StringBody, Rest$ImplicitMappingBody), none binary. So the clause is refused as MDL-REST02, the way MDL-REST01 refuses a mapping document inline. One function guards both the check pass and exec, and it sits in buildRestClientOperation, so --no-check does not reopen the silent write.

The refusal caught two shipped examples advertising a "File Upload" feature that never worked; 06-rest-client-examples.mdl is corrected.

2. 79c473f — binary POST, which is expressible

The commit above concluded binary upload was impossible and pointed at a Java action. That was the right answer about the wrong document. Mendix models a binary body on the microflow REST CALL activity:

"RequestHandling":     {"$Type": "Microflows$BinaryRequestHandling",
                        "Expression": "$FirstFileDoc/Contents"},
"RequestHandlingType": "Binary"

It is a Microflows$ type — which is why grepping the metamodel for Rest$*Body finds only the three non-binary ones and appears to prove it impossible. A Studio Pro example settled it in minutes.

mxcli could parse that shape and could neither write, read on the modelsdk engine, nor describe it. So a Studio Pro binary POST described as a REST call with no body at all, and re-executing that DESCRIBE produced a request that sent nothing.

Wired full-stack: grammar (BODY BINARY expression), AST, visitor, builder, both writers, the modelsdk reader, the formatter. The expression is the FileDocument's Contents member and is carried as source text — quoting it would send the path as a string literal. MDL-REST02's message, the syntax help and the examples now point here instead of at a Java action.

3. 733d6db — the export-mapping body, and a guard

generated/metamodel gives MicroflowsMappingRequestHandling exactly three properties: contentType (Json|Xml), mappingId, mappingVariableName.

Property	Studio Pro	mxcli before
RequestHandlingType	Mapping	Custom
variable key	MappingVariableName	ParameterVariable
ContentType	Json	''

So mxcli wrote a key the type does not own and omitted the real one — and an unknown property is the shape mxbuild tolerates and Studio Pro refuses to open. mxcli's own reader had known the correct key since mendixlabs#843; the writer was never corrected.

RequestHandlingType was hardcoded "Custom" in both engines regardless of handler; it is now derived. (The previous commit derived only Binary, the one case with a reference at the time — four examples made the rule measurable rather than guessed.)

Finally, FormDataRequestHandling and AdvancedRequestHandling can be parsed and not written, so a rewrite dropped the body silently. That is now refused (guard-don't-drop, ADR-0005), mirroring the queued-call guard. Its allow-list is the writable set, so it stops refusing the moment a type becomes expressible — as Binary just did.

Testing

Each fix was written test-first and fails on revert. Verified by round-tripping Studio Pro's own microflows and diffing the BSON — mxcli now reproduces the binary and export-mapping actions exactly (same $Type, discriminator and properties), and the form-data microflow is refused by name instead of silently emptied.

go test ./... green, make check-mdl 354 PASS / 0 FAIL, gofmt clean — re-run after rebasing onto current main.

New fixtures: rest-file-request-body.fail.mdl, rest-binary-post.mdl. Three symptom rows appended to fix-issue.md. Syntax help and MDL_QUICK_REFERENCE.md updated.

Also adds cmd/bsondump, a dev helper printing a .mxunit as canonical extended JSON — the technique the symptom rows prescribe, since bson.M loses key order and non-canonical extJSON hides int32 vs int64.

Not fixed here

• The legacy engine encodes MappingId as binary where Studio Pro stores a qualified-name string. Changing an ID encoding without a test showing that path ever worked is the kind of blind change these bugs came from. Noted in the symptom table.
• Authoring form-data bodies (only the refusal is here).
• Four Studio Pro divergences found while chasing the import-range bug and proven not causal: int32 vs int64 on 14 mapping numerics, root MinOccurs 0 vs 1, missing MessageDefinition2, blanked OriginalValue — each real and still unfixed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dp1syGhH8yr7Hve2wwjzqg

---

Generated by Claude Code