Summary
mxcli lint reports CONV013 on Java action, REST and web service calls that do have custom error handling, and never reports CONV014 for on error continue on an action.
⚠ Java action call in 'LintEh.MF_Handled' uses '' error handling instead of Custom. [CONV013]
For the same microflow, describe shows the handler (on error { … }) and mx check reports 0 errors. The '' in the message is the giveaway: the rule reads an empty field.
Reproduce
On a blank Mendix 11.12.1 app, exec this script (four microflows calling one Java action), then mxcli lint -p app.mpr:
create module LintEh;
create java action LintEh.JA_Echo (Text: string not null) returns string
as $$
return Text;
$$;
/
create microflow LintEh.MF_Handled ($Text: string)
begin
call java action LintEh.JA_Echo (Text = $Text) on error {
log error node 'LintEh' 'echo failed';
};
end;
/
create microflow LintEh.MF_HandledNoRollback ($Text: string)
begin
call java action LintEh.JA_Echo (Text = $Text) on error without rollback {
log error node 'LintEh' 'echo failed';
};
end;
/
create microflow LintEh.MF_Unhandled ($Text: string)
begin
call java action LintEh.JA_Echo (Text = $Text);
end;
/
create microflow LintEh.MF_Continue ($Text: string)
begin
call java action LintEh.JA_Echo (Text = $Text) on error continue;
end;
/Results on main (86d395e):
| microflow |
describe |
CONV013 |
CONV014 |
MF_Handled |
on error { … } |
⚠ uses '' (should be none) |
— |
MF_HandledNoRollback |
on error without rollback { … } |
⚠ uses '' (should be none) |
— |
MF_Unhandled |
no clause |
⚠ uses '' (should say Rollback) |
— |
MF_Continue |
on error continue |
⚠ uses '' |
none (should fire) |
mx check: 0 errors.
Cause
Mendix stores error handling on the action (Microflows$*Action.ErrorHandlingType), and that is where the reader puts it. The activity-level BaseActivity.ErrorHandlingType is left empty. The comment in mdl/backend/modelsdk/microflow.go says so: "it lives on the action".
CONV013 and CONV014 (mdl/linter/rules/conv_error_handling.go) read the activity field, so they always see "":
- CONV013 flags every Java/REST/web service call, whatever its handling;
- CONV014 can never match
Continue on an action.
describe is right because getActionErrorHandlingType in mdl/executor/cmd_microflows_show_helpers.go reads the action, using the reflection lookup from #1078. The linter never used it.
The rule's unit tests pass because they build the activity by hand with the handling on the activity, the one place the reader never puts it.
Proposed fix
Move the action-level lookup into sdk/microflows as ActionActivity.ErrorHandling(), which reads the action and falls back to the activity field for action types without one. Use it in both rules and in getActionErrorHandlingType, so the describer and the linter cannot drift apart again. The result on the repro above: CONV013 on MF_Unhandled (Rollback) and MF_Continue only, and CONV014 on MF_Continue. I have this ready with tests and can open a PR.
Environment: mxcli main 86d395e (also v0.24.0), Mendix 11.12.1, macOS.
Summary
mxcli lintreports CONV013 on Java action, REST and web service calls that do have custom error handling, and never reports CONV014 foron error continueon an action.For the same microflow,
describeshows the handler (on error { … }) andmx checkreports 0 errors. The''in the message is the giveaway: the rule reads an empty field.Reproduce
On a blank Mendix 11.12.1 app, exec this script (four microflows calling one Java action), then
mxcli lint -p app.mpr:Results on main (86d395e):
describeMF_Handledon error { … }uses ''(should be none)MF_HandledNoRollbackon error without rollback { … }uses ''(should be none)MF_Unhandleduses ''(should sayRollback)MF_Continueon error continueuses ''mx check: 0 errors.Cause
Mendix stores error handling on the action (
Microflows$*Action.ErrorHandlingType), and that is where the reader puts it. The activity-levelBaseActivity.ErrorHandlingTypeis left empty. The comment inmdl/backend/modelsdk/microflow.gosays so: "it lives on the action".CONV013andCONV014(mdl/linter/rules/conv_error_handling.go) read the activity field, so they always see"":Continueon an action.describeis right becausegetActionErrorHandlingTypeinmdl/executor/cmd_microflows_show_helpers.goreads the action, using the reflection lookup from #1078. The linter never used it.The rule's unit tests pass because they build the activity by hand with the handling on the activity, the one place the reader never puts it.
Proposed fix
Move the action-level lookup into
sdk/microflowsasActionActivity.ErrorHandling(), which reads the action and falls back to the activity field for action types without one. Use it in both rules and ingetActionErrorHandlingType, so the describer and the linter cannot drift apart again. The result on the repro above: CONV013 onMF_Unhandled(Rollback) andMF_Continueonly, and CONV014 onMF_Continue. I have this ready with tests and can open a PR.Environment: mxcli main 86d395e (also v0.24.0), Mendix 11.12.1, macOS.