Summary
The dashboard currently presents synthesized WAL and RocksDB activity as if it were real server telemetry. This creates a production-risking observability gap: operators can see inserts, flushes, merges, and compaction-like counters that never occurred on the HLQuery server. The issue should be to replace fabricated metrics with real backend data, or explicitly degrade the UI to an “unsupported/unavailable” state when the server does not expose the required endpoints.
Context
hanalyzer is positioning itself as a production-ready operational dashboard for a high-performance search engine, so telemetry accuracy matters as much as UI polish.
Today, the WAL timeline is generated from random values instead of server events:
src/composables/useWALTimeline.js calls /stats, then creates synthetic events with Math.random() and comments that this is only a placeholder for a future WAL endpoint.src/components/WALTimelineView.vue renders those generated events as authoritative operational history.
The RocksDB visualization also simulates live activity:
src/components/RocksDB3DDashboard.vue updates flush/merge/compact counters every 2 seconds using Math.random().
At the same time, src/views/ServerProfileView.vue and the README frame the dashboard as a serious monitoring interface. For a search engine wrapper around RocksDB, incorrect write-path telemetry is worse than missing telemetry because it can mislead debugging, capacity planning, and incident response.
Proposed Implementation
-
Define a strict telemetry contract for dashboard-only operational data.
The frontend should only render WAL, compaction, flush, merge, and related activity when the backend returns explicit fields or an endpoint dedicated to those events.
-
Replace synthetic timeline generation with capability-based loading.
If HLQuery exposes a WAL/history endpoint, read from it directly. If it does not, show a clear empty/unsupported state such as “WAL telemetry is not available on this server version” instead of inventing events.
-
Remove all Math.random()-driven operational counters from the RocksDB dashboard.
If only partial RocksDB stats are available, render only the real fields and gray out the rest with labels like “not reported”.
-
Add a telemetry source model in the UI.
Each dashboard section should know whether its data is live, stale, partial, or unsupported, and the visual treatment should reflect that state.
-
Add regression tests around telemetry truthfulness.
Component/composable tests should fail if WAL events or RocksDB counters are produced without backend data, ensuring placeholder logic cannot silently ship again.
Impact
Fixing this restores trust in the dashboard. Operators will make decisions based on real HLQuery behavior instead of fabricated activity, which is critical for diagnosing indexing issues, write amplification, compaction pressure, and storage performance. In a high-performance search engine environment, honest absence of telemetry is far safer than false-positive observability.
Summary
The dashboard currently presents synthesized WAL and RocksDB activity as if it were real server telemetry. This creates a production-risking observability gap: operators can see inserts, flushes, merges, and compaction-like counters that never occurred on the HLQuery server. The issue should be to replace fabricated metrics with real backend data, or explicitly degrade the UI to an “unsupported/unavailable” state when the server does not expose the required endpoints.
Context
hanalyzeris positioning itself as a production-ready operational dashboard for a high-performance search engine, so telemetry accuracy matters as much as UI polish.Today, the WAL timeline is generated from random values instead of server events:
src/composables/useWALTimeline.jscalls/stats, then creates synthetic events withMath.random()and comments that this is only a placeholder for a future WAL endpoint.src/components/WALTimelineView.vuerenders those generated events as authoritative operational history.The RocksDB visualization also simulates live activity:
src/components/RocksDB3DDashboard.vueupdates flush/merge/compact counters every 2 seconds usingMath.random().At the same time,
src/views/ServerProfileView.vueand the README frame the dashboard as a serious monitoring interface. For a search engine wrapper around RocksDB, incorrect write-path telemetry is worse than missing telemetry because it can mislead debugging, capacity planning, and incident response.Proposed Implementation
Define a strict telemetry contract for dashboard-only operational data.
The frontend should only render WAL, compaction, flush, merge, and related activity when the backend returns explicit fields or an endpoint dedicated to those events.
Replace synthetic timeline generation with capability-based loading.
If HLQuery exposes a WAL/history endpoint, read from it directly. If it does not, show a clear empty/unsupported state such as “WAL telemetry is not available on this server version” instead of inventing events.
Remove all
Math.random()-driven operational counters from the RocksDB dashboard.If only partial RocksDB stats are available, render only the real fields and gray out the rest with labels like “not reported”.
Add a telemetry source model in the UI.
Each dashboard section should know whether its data is
live,stale,partial, orunsupported, and the visual treatment should reflect that state.Add regression tests around telemetry truthfulness.
Component/composable tests should fail if WAL events or RocksDB counters are produced without backend data, ensuring placeholder logic cannot silently ship again.
Impact
Fixing this restores trust in the dashboard. Operators will make decisions based on real HLQuery behavior instead of fabricated activity, which is critical for diagnosing indexing issues, write amplification, compaction pressure, and storage performance. In a high-performance search engine environment, honest absence of telemetry is far safer than false-positive observability.