Fix: persist and read back consumed REST operation mappings (#843)

[ako]

Fixes mendixlabs#843.

Symptom

create rest client reports success. describe rest client then omits Query:, Parameters: and Headers: entirely, and always prints Response: none. mx check reports 0 errors, so nothing anywhere complains.

Dumping the stored BSON for the reporter's script shows the split:

"QueryParameters": [2, {"$Type": "Rest$QueryParameter", "Name": "page"}, ...]   ← stored fine
"Headers":         [2, {"$Type": "Rest$HeaderWithValueTemplate", ...}]          ← stored fine
"ResponseHandling": {"$Type": "Rest$NoResponseHandling"}                        ← mapping gone

Three defects behind one symptom

1. Write path — a case-sensitive comparison whose false branch is silent

model.RestClientOperation documents BodyType/ResponseType as upper-case tokens, and every consumer compares against that spelling — both serializers and the REST-call microflow builder. The MDL executor stored the visitor's lower-case source text:

op.ResponseType = "mapping"                    // mdl/executor/cmd_rest_clients.go
...
if op.ResponseType == "MAPPING" && ... {       // mdl/backend/modelsdk/consumed_rest_write.go
    addPart(g, "ResponseHandling", restImplicitMappingResponseToGen(...))
} else {
    addPart(g, "ResponseHandling", restResponseHandlingToGen(...))   // ← always taken
}

The mapping was dropped on every response mapping authored in MDL, not just the reporter's syntax — a fully correct Response: mapping Mod.Entity { Attr = field } was lost too. Nothing errored because the else-branch is a legitimate outcome for an operation with no mapping, so a producer/consumer mismatch got laundered into a plausible-looking model.

Fixed by normalizing with strings.ToUpper at the one place the AST becomes the semantic model, and making the two serializer comparisons EqualFold so the landmine isn't left armed for the next producer. (The OpenAPI import path already emits the documented upper-case form, which is why it was unaffected.)

2. Read path — one type assertion for two different gen types

restOperationFromGen populated only Name/HttpMethod/Path/Timeout, and type-asserted *genRest.RestParameter for both parameter lists. The writer emits Rest$OperationParameter and Rest$QueryParameter — two different types — so both assertions fell to ok=false and skipped every item. Headers and ResponseHandling weren't read at all.

Now reads parameters (with DataType), query parameters, headers, the response handler and the body, including the ImportMappings/ExportMappings element trees. This also repairs shouldSetBodyVariable, which could never observe EXPORT_MAPPING because BodyType was never populated.

3. The reporter's actual syntax is not expressible in Mendix

Response: mapping ZZB."IMM_R10" names an import mapping document. The clause expects a target entity plus a { ... } body — Mendix stores the mapping inline on the operation and has nowhere to put a document reference. Rest$RestOperationResponseHandling has exactly two implementations:

// generated/metamodel/types.go:738
// RestOperationResponseHandling is implemented by: ImplicitMappingResponseHandling, NoResponseHandling

So it parsed, named a document where an entity belongs, contributed no field mappings, and was written as "no response handling" — in silence. Now refused at exec time and at mxcli check time (MDL-REST01, no project needed):

Error: operation "SearchRoutes": Response: mapping ZZB.IMM_R10 has no mapping body.
  A consumed REST operation cannot reference an import/export mapping document;
  Mendix stores the mapping inline, so the fields must be listed here.
  Name the target entity and its fields:
    Response: mapping Module.Entity { Attribute = jsonField, ... }

One deliberate non-fix

Rest$QueryParameter stores no DataType — Mendix does not model a type for query parameters, so the one written in MDL is dropped at write time and there is nothing to read back. The grammar still requires $name: Type, so describe emitted $page: , which does not re-parse. It now emits String. Reconstructing the authored type would be inventing a value the model does not hold — the mistake fixed in mendixlabs#840.

Validation

Mendix 11.13.0, fresh projects via mxcli new:

	before	after
reporter's script	silent success, mapping lost	fails loudly with the syntax to use
corrected script → ResponseHandling	Rest$NoResponseHandling	Rest$ImplicitMappingResponseHandling + full ImportMappings$ObjectMappingElement tree
describe rest client	Response: none, no Query/Parameters/Headers	all clauses present
mx check	0 errors	0 errors
describe → exec → describe	n/a	byte-identical (fixed point)

• Tests written first; all three fixes reverted independently to confirm each is the cause of its test's failure (Parameters = 0, want 1 / lowercase "mapping" lost the response mapping / ResponseType = "json", want "JSON").
• go test ./..., make check-mdl green.
• The pre-existing round-trip test built an operation with a query parameter but only asserted the operation count — which is why this shipped. The new test asserts the parameter survives.

Changes

File	Change
mdl/executor/cmd_rest_clients.go	normalize type tokens; checkInlineMappingBody; restParamTypeOrDefault
mdl/backend/modelsdk/integration_read.go	correct type assertions; read headers, response, body, mapping trees
mdl/backend/modelsdk/consumed_rest_write.go	EqualFold on the two silent-drop comparisons
modelsdk/mpr/serialize_web_services.go	same, other engine
mdl/executor/validate_rest_mapping.go	new — MDL-REST01 check-time rule
cmd/mxcli/cmd_check.go	wire the rule into the no-project pass
cmd/mxcli/syntax/features_integration.go	Query:/Timeout: in help; entity-not-document note
.claude/skills/mendix/rest-client.md	document the entity-plus-body rule and the reuse alternative
.claude/skills/fix-issue.md	symptom row
mdl-examples/bug-tests/843-*.mdl	positive repro + .fail.mdl negative test

🤖 Generated with Claude Code

https://claude.ai/code/session_01LUToAkUx54bNkNjsBpufRH

---

Generated by Claude Code