Repository navigation
feat(api): expose the cache figure the System Info page shows - #3433
vpetersson-bot wants to merge 1 commit into
Conversation
/api/v2/info carried memory.buff, the kernel's raw "Buffers" line alone. The System Info page's "Buffers / cache" row is a different, much larger quantity: buffers + page cache + shared, derived as total - used - free. No field in the API response let a client reconstruct it, so the two surfaces disagreed with no way to reconcile them. On an x86 test device the page read 3,129 MiB while the API's buff read 878 at the same moment. Add memory.cache alongside memory.buff, and derive both the page row and the new field from one memory_cache_mib() helper so they cannot drift apart again. Additive only: buff keeps its meaning and every existing field is untouched, so current clients are unaffected. Refs: https://forums.screenly.io/t/api-memory-discrepancy/6721 Closes #3432 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
|
|
Note on the red |
What is wrong today
/api/v2/inforeturnsmemory.buff, which is the kernel's rawBuffersline on its own. The System Info page shows a row labelled Buffers /
cache, which is a different and much larger quantity: buffers + page cache
page_context.system_info()astotal - used - free.No field in the API response carried that second quantity, so a client had
nothing to reconcile the two with. Reading
buffas "the cache figure" isthe obvious move and it is wrong by a wide margin.
Measured on an x86 test device at the same moment:
/api/v2/infomemory.buffWhat this changes
memory_cache_mib()toanthias_common.utils, the single definitionof the reclaimable slice.
page_context.system_info()now calls it instead of computing the figureinline, so the page is unchanged but no longer owns the formula.
get_memory()inapi/views/v2.pygainsmemory.cachefrom the samehelper, and the OpenAPI schema documents both fields and the difference
between them.
This is additive.
buffkeeps its exact meaning and value, no existing fieldchanges shape, and clients that ignore the new key are unaffected — so it
stays within the "never break the REST API" rule rather than needing a new
version.
How I know it is right
memory_cache_mibon the live values from the device above yields 3,129,matching the page exactly.
test_info_v2_endpoint's mock now usesused=3 GiB/free=4 GiBof an8 GiB total so
cacheis a non-zero 1,024 MiB, withbuffersset to adeliberately different 64 MiB — wiring
cachetobuffersby mistakewould fail the assertion rather than pass silently.
and the clamp that stops a kernel reporting odd values producing a negative
pie wedge.
ruff check,ruff format --checkandmypyare clean on the touched files.One pre-existing failure,
TestWaitForWaylandSocket:: test_probe_reports_not_ready_for_a_non_socket_path, shows up only underpytest -n autoand reproduces identically on an unmodified tree, so it isunrelated to this change.
Reported at https://forums.screenly.io/t/api-memory-discrepancy/6721
Closes #3432
🤖 Generated with Claude Code