[ako]

Closes #1448 (mirror of mendixlabs#1550). Closes #1654 (mirror of mendixlabs#1645).

mxcli test generated a flow that could not be built, so no test ran. One commit per issue. Both verified with mxcli test --local --db-type hsqldb on a blank 11.13.0 app.

#1448 — a call with its own on error clause got a second one

Cause: attachOnError (generator_endpoint.go) appended ON ERROR BEGIN … END ERROR to every line a regex matched, with no check for an existing clause; the legacy runner had two more copies of the same join, which also broke on a custom handler's own ; and on a trailing -- comment.

Fix:

• One parser-driven attachOnError for both runners, with and without @throws. New visitor.FlowStatements parses the body inside the generator's own wrapper and language version and returns each statement's span and its own ON ERROR clause; a body that does not parse is left unchanged. The regex is replaced by errorRaisingCallRules, a set of grammar rule names pinned by a test.
• on error continue and custom handlers are kept as written. on error rollback is replaced by the runner's handler: it is Mendix's default spelled out (the same ErrorHandlingType as no clause), and keeping it gave ERROR instead of FAIL, failed a matching @throws, and under the legacy runner aborted the suite.
• A false green found at runtime: a custom handler that ends normally rejoins the flow past every statement reading the failed call's output — past the @expect checks — and reported PASS with nothing evaluated. Each assertion now counts itself in both branches, and a guard fails the test with "not every assertion was evaluated" when the count is short (both runners).
• Legacy log parser: a RUN line with no verdict read as PASS (the zero status); it is now an ERROR saying the test started and gave no verdict.

Verdict table (Java action that throws, endpoint runner):

Clause	@expect	@throws 'boom'
none (control)	FAIL exception during execution: boom: a	PASS
on error rollback	FAIL, same as none	PASS
on error continue	FAIL expected $r = 'X', actual:	FAIL expected an exception but none was thrown
custom handler, ends normally	FAIL not every assertion was evaluated (was PASS)	FAIL expected … none was thrown
custom handler, re-raises	ERROR boom: a	ERROR boom: a

The issue's statements with succeeding calls PASS; an @expect on a flag the handler sets still PASSes; --legacy-runner gives the same verdicts.

#1654 — CE0114 on the generated startup flow

Measured with mx check 11.13.0, security Off and Production: a non-applying microflow calling an applying one is CE0114; an applying one calling either kind is 0 errors (MDL-SEC22 records the same for 11.14.0).
Cause: GenerateEndpointMDL wrote MxTest.RegisterEndpoint without the setting, and it calls the project's after-startup microflow. Separately, buildFailureHint called every error outside a Test_* flow "in the project".
Fix: RegisterEndpoint always carries @applyentityaccess — the measured direction makes a constant correct for every project, with nothing to read from the user's microflow. Errors located in mxcli's generated MxTest flows are reported as mxcli's own, with --skip-app-startup as the escape hatch.

Verified

• Tests in own_error_handler_test.go, flow_statements_test.go, startup_entity_access_test.go; every generated script is parsed with visitor.Build. Cases: the clause on the next line; on error in a string, a line comment and a block comment; two calls on one line; a call nested in an IF or in the author's handler; the plain-call control.
• Revert proofs: always attaching reproduces "mismatched input 'ON' expecting ';'"; the rollback, counter and RUN-without-verdict stubs each fail their test; reverting [up#1645] mxcli test --local: the generated MxTest.RegisterEndpoint does not apply entity access, so a project whose after-startup microflow does cannot be tested (CE0114) #1654 fails both its tests (the project-only control passes either way).
• Real app: baseline gives the reported parse error ([up#1550] mxcli test: a call with its own on error clause in a test block produces an unparsable test microflow ("mismatched input 'ON' expecting ';'") #1448) and CE0114 with "in the project" ([up#1645] mxcli test --local: the generated MxTest.RegisterEndpoint does not apply entity access, so a project whose after-startup microflow does cannot be tested (CE0114) #1654); fixed, both suites run with the verdicts above, and the [up#1645] mxcli test --local: the generated MxTest.RegisterEndpoint does not apply entity access, so a project whose after-startup microflow does cannot be tested (CE0114) #1654 marker test proves the startup microflow ran at boot (FAILs under --skip-app-startup, the control). A non-applying startup microflow still PASSes.
• Full go test ./..., go vet, gofmt and CI's doc checks pass with all five of this batch's branches merged onto main. Bug-test material test-runner-1448-*, test-runner-1654-*; findings recorded; test-microflows skill, docs-site test-annotations and running-tests updated.
• Not verified: run --local --test-endpoint with test --attach for [up#1645] mxcli test --local: the generated MxTest.RegisterEndpoint does not apply entity access, so a project whose after-startup microflow does cannot be tested (CE0114) #1654 (same generator, unit test only); the Docker path; CE0114 on Mendix 10.x.

Noticed, not fixed

1. Legacy runner false green (Docker default and --legacy-runner): a later assertion's PASS line overwrites an earlier FAIL (results.go case "PASS"), so a test whose first @expect fails and second passes reports PASS. Confirmed at unit level.
2. Legacy runner: assignPattern matches only upper-case CALL|CREATE, so mdl 1's $r = call … is not renamed per test; two tests using $r fail injection (MDL063 / CE0111, measured).
3. Endpoint @throws false red: an error that leaves the test microflow (a re-raising handler, or a non-call activity) is reported ERROR instead of being checked against @throws.
4. run --local --test-endpoint does not use buildFailureHint, so it lacks the new attribution.

🤖 Generated with Claude Code