Repository navigation
get_server_info walks every cache tree on each call #840
Description
From the 2026-10-11 develop review.
dw_mcp/workspaces.py server_info now fetches /api/caches on every get_server_info call, and that route stat()-walks the whole inductor, triton and quantized trees synchronously (plus a mark_root attempt per cache). The call every MCP session opens with grows with the number of cached kernels.
Failure: a box with tens of thousands of Triton kernel files and a multi-GB inductor cache pays a full tree walk per get_server_info; the MCP summary only needs byte counts.
Fix direction: cache the scan for a few seconds server-side, or compute the per-cache sizes lazily / in a background refresh and serve the last value.
Activity
dkackman commentedon Oct 12, 2026
triage: batch with #838, #839, #840, #841 — all in dw/disk_caches.py and the /api/caches route (clear lock, staging sweep, scan cost, mark_root logging); one fix, one server restart. (claude-opus-5-5 via anthropic)
fix(caches): #838 #839 #840 #841 - clear holds the job queue; sweep o…
dkackman commentedon Oct 12, 2026
Fixed in 5dc3ff4 on develop:
scan_all()reuses its result for 5 s (_SCAN_TTL), dropped on any clear/entry delete. Applies to GET /api/caches and so get_server_info.scan()itself is uncached. Tests: reuse until clear; rescan after TTL. Only mark_root calls on the scan path were via_reason(see #841).Batch #838/#839/#840/#841, one commit. Tests pass in the source checkout (tests/test_disk_caches.py, test_server.py, test_api_contract.py; OpenAPI doc regenerated for the changed route docstrings). The full suite's 18 other failures are Kandinsky6 tests that fail on develop without this change. Not deployed by me: the driver deploys develop to mini-ai before the tester runs. Server restart needed; no breaking MCP change. Hard to verify over MCP: the race itself (window is milliseconds); verifiable is DELETE /api/caches/ still returning 200/409/400 as before and get_server_info caches summary still present.
— claude-sonnet-5-5 via anthropic
dkackman commentedon Oct 12, 2026
Tester on mps on mini-ai.lan (develop @ 68ba49b), claude-opus-5-5 via anthropic.
Ran
get_server_infotwice back to back. Both returned 200 with thecachessummary intact and identical: inductor (enabled, clearable), triton (disabled), quantized (withentry_count). Each entry carriesbytes,filesanddisk_free. So the summary didn't regress.The fix itself can't be observed here. Every cache on this box is empty (
bytes: 0, files: 0across all three), and triton is disabled on mps. That means a tree walk costs nothing whether or not the 5 s reuse is in place. The failure the issue describes needs a populated inductor or Triton cache, which only lem has. I'm handing this to lem's loop.Suggested check on lem: call
get_server_infoand note the non-zero cachebytes/files. Then call it two or three times within 5 s, usingdatebetween calls for coarse timing. The calls should all succeed with the same numbers, and the repeats shouldn't be slower than the first. Clearing caches is only exposed on the server page, not over MCP, so the invalidation-on-clear path stays covered by the unit tests only.dkackman commentedon Oct 12, 2026
Verified on lem (cuda, develop @ 68ba49b) — tester, claude-opus-5-5 via anthropic.
Ran the check suggested in the mini-ai hand-off, this time against populated caches:
get_server_infoonce, then twice more in a single batch. All three returned the fullcachessummary with identical numbers:entry_count18enabled/clearable/disk_freepresent on each.datebefore the first call to thedateafter the last was 2.19 s. That covers threeget_server_infocalls plus the agent turn overhead. No call was slow.What I couldn't observe: this box has about 3.6k kernel files. At that size a full walk and a reuse within the 5 s window both finish under turn-latency resolution, so this confirms correct and consistent results, not the TTL itself. The TTL and invalidate-on-clear paths are covered by the implementer's unit tests. Clearing isn't exposed over MCP.
No regression case added: the existing summary shape is already exercised, and the timing isn't measurable at MCP resolution.