Skip to content

fix(rest): derive published REST operation parameters from the microflow - #1207

Open
tgolembiewski wants to merge 1 commit into
mendixlabs:mainfrom
tgolembiewski:fix/published-rest-operation-params
Open

tgolembiewski wants to merge 1 commit into
mendixlabs:mainfrom
tgolembiewski:fix/published-rest-operation-params

Conversation

@tgolembiewski

Copy link
Copy Markdown
Contributor

Closes #1206

What

create published rest service wrote only the path's {name} placeholders as operation parameters, each as a String. Every other microflow parameter failed mx check:

  • a query parameter with CE0350;
  • a body or a file upload with CE0350;
  • an {id} bound to an Integer with CE6539.

MDL has no syntax for operation parameters, so these operations could not be built at all.

Studio Pro derives an operation's parameters from its microflow (Published REST Operation). This PR does the same when the service is written:

Microflow parameter Operation parameter
named in the path a path parameter, with the microflow parameter's type
an object or a list the body
System.HttpRequest, System.HttpResponse none; they are the request and the response
anything else a query parameter

No new syntax. create and alter both derive the parameters, since alter writes every operation again and the reader does not read parameters back.

If the microflow does not exist yet, the operation keeps today's path-only parameters, and exec prints a warning that names the microflow and the CE0350 to expect.

Measured on a blank Mendix 11.12.1 app with mdl-examples/bug-tests/published-rest-operation-parameters.mdl:

mx check
v0.24.0 4 errors (3 × CE0350, 1 × CE6539)
main at bf119f6 4 errors, the same
this PR 0

At runtime, GET rest/orders/v1/orders/status?orderNumber=ORD%2F2026%2F0012&count=3 answers ORD/2026/0012:3, so the runtime binds the query parameters, slashes included.

Changes

  • mdl/executor/cmd_published_rest.go:
    • deriveOperationParameters / operationParametersOf map the microflow's parameters with the rule above;
    • called before create and alter write the service;
    • the warning when the microflow is missing.
  • model/types.go:
    • PublishedRestOperation.OperationParameters and PublishedRestOperationParameter (name, kind, data type, entity or enumeration);
    • PathParameterNames(), moved from the writer's extractPathParams so the executor and the writer read the path the same way.
  • mdl/backend/modelsdk/published_rest_write.go:
    • writes the derived parameters with their own types;
    • falls back to String path parameters when there are none.
  • Docs:
    • mxcli syntax rest.published says where operation parameters come from;
    • so does docs-site/src/examples/rest-integration.md, which also drops "{id} requires $id: String".
  • mdl-examples/bug-tests/published-rest-operation-parameters.mdl: the repro.
  • CHANGELOG.md ([Unreleased] / Fixed), and one line in .claude/skills/fix-issue/findings/mdl-executor.jsonl.

Tests

  • New tests:

    • TestDeriveOperationParameters_AsStudioPro: Path with an Integer type, Query including an enumeration, Body for an object and a list, HttpRequest / HttpResponse left out;
    • TestDeriveOperationParameters_WarnsWhenTheMicroflowIsMissing;
    • TestCreateAndAlterPublishedRestService_DeriveParameters: both statements hand the backend derived parameters, and alter derives them for the operations it did not touch;
    • TestCreatePublishedRestService_WritesDerivedParameters: the stored Rest$RestOperationParameter BSON (kind, type, MicroflowParameter) and the String path fallback.
  • Each part of the fix was stubbed out in turn, and each time a test failed (8 of 8):

    • the call in create;
    • the call in alter;
    • object/list as Body;
    • skipping HttpRequest;
    • path over query;
    • the warning;
    • the writer using the derived parameters;
    • the writer keeping their types.
  • No regression on the repo's example: mdl-examples/doctype-tests/22-published-rest-service-examples.mdl gives 0 mx check errors before and after.

  • Round trip: re-executing describe published rest service output reports every service Unchanged and leaves every .mxunit byte-identical, for the repro and for the doctype example.

  • The whole of push-test.yml ran locally on macOS, all green:

    • build and make test;
    • lint-go, check-mdl, check-findings, check-wiki-pages and the tunnel deps;
    • the skill and docs-site MDL blocks;
    • integration tests against mx 11.12.1;
    • govulncheck.

    mdbook build docs-site (0.5.2) passes too.

Not in this PR

Each is noted in #1206:

  • A body that is not a file document also needs an import mapping (CE6541). IMPORT MAPPING, EXPORT MAPPING and COMMIT on an operation are parsed into the AST but never written. A separate fix.
  • Header parameters, which Studio Pro does not derive; they would need syntax.
  • Service authentication, since AuthenticationTypes is always written empty.

create published rest service wrote only the path's {name} placeholders as
operation parameters, each as a String. Any other microflow parameter failed
mx check with CE0350, and an {id} bound to an Integer failed CE6539. MDL has
no syntax for operation parameters, so a query parameter, a body or an upload
could not be built; a generated app parsed HttpRequest/Uri by hand instead.

Studio Pro derives them from the microflow: a parameter named in the path is
a path parameter, an object or a list is the body, System.HttpRequest and
HttpResponse are left out, and anything else is a query parameter. create
and alter now do the same before the service is written, each parameter with
the microflow parameter's own type. When the microflow does not exist yet,
the operation keeps its path parameters and exec says so.

Measured on Mendix 11.12.1 with
mdl-examples/bug-tests/published-rest-operation-parameters.mdl: 4 mx check
errors on v0.24.0 and on main, 0 with this change. At runtime
GET .../status?orderNumber=ORD%2F2026%2F0012&count=3 answers ORD/2026/0012:3,
and re-executing describe output leaves the service unchanged.

Refs mendixlabs#1206
@github-actions

Copy link
Copy Markdown

AI Code Review

Critical Issues

None found.

Moderate Issues

None found.

Minor Issues

  • In mdl/executor/cmd_published_rest.go, the deriveOperationParameters function could benefit from extracting the path parameter detection logic into a shared helper rather than duplicating the path parsing (though this is minor since the logic is simple and used in only two places).
  • The warning message in deriveOperationParameters uses string concatenation that could be formatted with fmt.Sprintf for better readability, but this is a style preference.

What Looks Good

  • Complete fix: The PR fully addresses issue create published rest service writes only path parameters: query and body parameters fail mx check (CE0350, CE6539) #1206 by deriving operation parameters from microflow parameters exactly as Studio Pro does.
  • Proper architecture: Changes are correctly placed in the executor layer where they belong, with no unnecessary modifications to grammar/AST/visitor layers since no new syntax is added.
  • Comprehensive testing:
    • New unit tests cover all parameter types (path, query, body) and special cases (HttpRequest/HttpResponse skipped)
    • Tests verify both create and alter statements work correctly
    • Warning behavior when microflow is missing is tested
    • Integration tests confirm the fix resolves mx check errors
    • Round-trip testing shows DESCRIBE output is stable
  • Documentation updated:
    • CLI syntax help reflects that operation parameters come from the microflow
    • Rest integration docs updated with clear explanation and example
    • Removed outdated note about {id} requiring $id: String
  • Backward compatibility:
    • When microflow is missing, falls back to original behavior (path parameters as String)
    • Warning message helps users understand expected mx check errors
    • Alter statement correctly derives parameters for all operations, not just modified ones
  • Code quality:
    • Clean separation of concerns (derivation logic in dedicated functions)
    • Proper use of type switches for microflow parameter handling
    • Correct BSON storage of derived parameters with appropriate types
    • No regression in existing functionality (doctype tests still pass)

Recommendation

Approve the PR. It correctly implements the fix for issue #1206 by deriving published REST operation parameters from microflow parameters matching Studio Pro's behavior. The changes are minimal, focused, well-tested, and properly documented. The solution follows the project's architectural patterns and maintains backward compatibility while resolving the mx check failures described in the issue.


Automated review via OpenRouter (Nemotron Super 120B) — workflow source

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

create published rest service writes only path parameters: query and body parameters fail mx check (CE0350, CE6539)

1 participant