Catalog java actions return type confusing in case of typeparam named after primitive

[mkrouwel]

mxcli 0.24
mx 11.12.3

There seems to be a change in the catalog java_actions(_data) where the returntype in case of typeparameter/entity has been changed. Sometimes the value is 'TypeParameter', sometimes TypeParEntity, and sometimes the name of the TypeParameter, e.g. FileTypeDocument (in case of OQL.ExportOQLToCSV).
However, when I create a Java action with a TypeParameter named String, which is allowed by Studio, and use that as return type, the catalog will show 'String', similar to the primitive 'String'.
The convention for return types using type parameters should be revised.

[github-actions]

Issue Triage

Summary:
The reporter notes that the return type shown in the catalog for Java actions using type parameters is inconsistent (sometimes “TypeParameter”, sometimes “TypeParEntity”, sometimes the actual type name, and sometimes indistinguishable from a primitive string), and suggests the convention should be revised.

Checklist of required information for a bug report

Required info	Present?
mxcli version (output of mxcli --version or commit/build)	❌
Mendix version of the project being processed	❌
Scenario (what the user was trying to do – CLI command, MDL script, etc.)	❌
Expected output (what should have happened)	❌
Experienced output (what actually happened – error, wrong result, crash)	❌
AI bug report (output of mxcli diag --bundle or at least the session log)	❌

Next steps
To help us investigate, could you please provide the missing details listed above? Specifically:

1. The version of mxcli you’re using.
2. The Mendix version of the project you’re analyzing.
3. The exact command or steps you ran that produced the catalog output.
4. What you expected the return type to look like for a Java action with a TypeParameter named String.
5. What you actually observed (the confusing values you mentioned).
6. If possible, run mxcli diag --bundle and attach the resulting archive, or at least share the relevant session log.

Thanks for bringing this to our attention—once we have the extra information we’ll be able to look into the issue more effectively!

---

Automated triage via OpenRouter — workflow source