REFRESH CATALOG SOURCE leading to timeout (5mins)

[PhetoJob]

Using mxcli on cloud-portal (huge mendix app/project) when using REFRESH CATALOG SOURCE leads to a timeout:

mxcli -p cloud-portal.mpr -c "REFRESH CATALOG SOURCE"
WARNING: This is a vibe-coded PoC, alpha quality, use with caution.
Connected to: cloud-portal.mpr (Mendix 9.24.40.80973)
Cache invalid: source mode requested but cache is full mode
Widget definitions: 0 new, 4 refreshed
Building catalog (source mode - includes MDL source)...
✓ Modules: 86
✓ Entities: 975
✓ Attributes: 3780
✓ Associations: 632
✓ Enumerations: 293
✓ Constants: 327
✓ ConstantValues: 500
✓ Java Actions: 359
✓ Microflows: 3259
✓ Nanoflows: 81
✓ Activities: 33597
✓ Pages: 541
✓ Widgets: 0
✓ Snippets: 134
✓ Layouts: 64
✓ OData Clients: 0
✓ OData Services: 0
✓ Business Event Services: 7
✓ widget_definitions: 78
✓ Database Connections: 0
✓ JAR Dependencies: 0
✓ REST Clients: 0
✓ Published REST Services: 16
✓ Published REST Operations: 177
✓ External Entities: 0
✓ External Actions: 0
✓ Business Events: 0
✓ Contract Entities: 0
✓ Contract Messages: 51
✓ Navigation profiles: 1
✓ Navigation menu items: 92
✓ Navigation role homes: 5
✓ RoleMappings: 165
✓ JSON Structures: 101
✓ Import Mappings: 183
✓ Export Mappings: 184
✓ References: 10529
✓ Permissions: 12628
✓ XPath Expressions: 1175
✓ strings: 7592
Error: statement timed out after 5m0s

Is there any way of configuring the timeout?

[github-actions]

Issue Triage

Summary:
The user reports that running mxcli REFRESH CATALOG SOURCE on a large Mendix 9.24 project times out after 5 minutes.

Checklist for bug report completeness

Required info	Present?	Notes
mxcli version	❌	Not mentioned
Mendix version	✅	9.24.40.80973
Scenario (what was tried)	✅	mxcli -p cloud-portal.mpr -c \"REFRESH CATALOG SOURCE\"
Expected output	❌	Implicit (should complete) but not explicitly stated
Experienced output	✅	Timeout error shown
AI bug report / session log	❌	No mxcli diag --bundle or log attached

What’s missing:

• The version of mxcli you’re using (mxcli --version).
• A clear statement of what you expected to happen (e.g., the command should finish and refresh the catalog).
• Diagnostic information: either the output of mxcli diag --bundle or at least the full session log leading up to the timeout.

Could you please add those details? Once we have them, we’ll be able to investigate the timeout and see if a configurable timeout option is needed. Thanks!

---

Automated triage via OpenRouter — workflow source

[PhetoJob]

mxcli version 0.12.0

[ako]

Thanks for the report — diagnosed and fixed.

Root cause: REFRESH CATALOG SOURCE runs as a single MDL statement, and every statement is wrapped in a generic 5-minute wall-clock guard (meant to abort runaway loops). On a project this size (33k activities, 12k permissions, 10k references, ~3k microflows whose source is captured in source mode), the build legitimately runs past 5 minutes. Worse: when it fired, the process exited before the catalog cache was written, so no progress was ever saved and the refresh could never complete.

Immediate workaround (works on 0.12.0, no upgrade needed): the timeout is configurable via the MXCLI_EXEC_TIMEOUT env var — it accepts a Go duration or bare seconds:

MXCLI_EXEC_TIMEOUT=30m mxcli -p cloud-portal.mpr -c "REFRESH CATALOG SOURCE"

(It was documented but not surfaced in the error message — that's on us.)

Fix (committed):

• REFRESH CATALOG is now exempt from the default 5-minute guard, so it runs to completion on large projects without any env var. The output-line guard still applies, and an explicit MXCLI_EXEC_TIMEOUT still wins if you ever want to cap it.
• The timeout error is now actionable — it names MXCLI_EXEC_TIMEOUT with an example.

One heads-up: a full source build on a project this size is inherently heavy, so even uncapped it may take a while the first time. After it completes once, the result is cached (.mxcli/catalog.db) and subsequent runs are fast unless the project changed. If MXCLI_EXEC_TIMEOUT=30m still isn't enough for the first build, let us know the actual wall-clock time and we'll dig into the source-capture cost.

[PhetoJob]

Thanks! I was already hoping there was some env var to use for this (I had looked in and searched through the docs but could not find anything).

[PhetoJob]

@ako I tried running REFRESH CATALOG SOURCE with MXCLI_EXEC_TIMEOUT=30m but I still got a timeout. Currently running it with the timeout put on 999m but 2 hours in it is still stuck on the source step. I guess it might be stuck on some loop somewhere, but I have no way of figuring out anything additional. I cannot see anything in the mxcli logs itself. I also tried to see if there is some DEBUG feature or some setting for verbose logging, but using set -c verbose=true; REFRESH CATALOG SOURCE does not reveal anything additional.