Reported in #28: install noise plus an unusably slow UI on Debian 13 (1.7.24).
The catalog was re-scanned on every request
buildSourceSnapshot built the catalog signature — one stat per app, and the
CasaOS store ships ~1000 — before consulting the cache, so the 6h
STORE_CATALOG_TTL_MS never saved any work. Every /api/v1/store/apps call
walked the whole catalog, which on a low-power box pegs the CPU and starves the
libuv fs pool, stalling unrelated filesystem work across the app. Search was the
worst case: one full walk per debounced keystroke — exactly the reported symptom.
The cache is now checked first, and the signature is only revalidated every 30s.
Explicit syncs (refreshStoreCatalogSource) still bypass it, so refreshing a
source picks up changes immediately.
Metrics snapshots stacked on each other
collectSnapshot shells out to sensors / nmcli / ip. When it outran
METRICS_PUBLISH_INTERVAL_MS, each SSE tick started another collection on top of
the last until the subprocesses ate the CPU. Now single-flighted.
pg_lsclusters: not found
Cosmetic, but it reads like a failed install. apt preconfigures every package in
a batch before unpacking any, and the postgresql metapackage's debconf script
calls pg_lsclusters — which ships in postgresql-common. Installing that in
its own apt call first makes the message go away.
Tests
Two regression tests: a second catalog request issues zero extra stat calls,
and an app added on disk still appears once the 30s window elapses. Both fail
without the change.
Caveat
Not reproduced on Debian 13 — the reporter never came back with top /
journalctl output, so this fixes a bottleneck found by reading the hot path
rather than a confirmed diagnosis of his machine.
Refs #28
🤖 Generated with Claude Code