Refactor: Replace isATMActivated and monitor.menuEnabled with StorageCapabilities.metricsStorage
Problem
Three overlapping mechanisms currently control Monitor/SPM visibility in the UI:
monitor.menuEnabled — a static config flag (defaults true) that controls whether the Monitor tab appears in the nav. Redundant because the server already knows at startup whether metrics storage is configured.isATMActivated — a runtime probe that detects HTTP 501 responses from the metrics API and permanently disables the Monitor page for the session. Fragile because 501 can also indicate transient storage failures, and there is no retry logic.StorageCapabilities — server-reported capabilities injected into the UI at serve time (currently only reports archiveStorage). This is the right mechanism but doesn't yet cover metrics storage.
These three mechanisms are redundant and sometimes contradictory. A cleaner design uses a single source of truth: the server reports whether metrics storage is available via StorageCapabilities, and the UI trusts that.
Target Design
- Extend
StorageCapabilities with metricsStorage: boolean — the server sets this based on its configuration.
- Derive Monitor tab visibility from
storageCapabilities.metricsStorage instead of monitor.menuEnabled.
- Remove
isATMActivated from the UI state — no more runtime 501 probing to detect feature availability.
- Treat HTTP 501 as a normal API error — existing per-metric error fields already capture it; display errors rather than hiding the feature.
- Keep the "No data yet!" alert in ServicesView for configured-but-empty scenarios.
Refactor: Replace
isATMActivatedandmonitor.menuEnabledwithStorageCapabilities.metricsStorageProblem
Three overlapping mechanisms currently control Monitor/SPM visibility in the UI:
monitor.menuEnabled— a static config flag (defaultstrue) that controls whether the Monitor tab appears in the nav. Redundant because the server already knows at startup whether metrics storage is configured.isATMActivated— a runtime probe that detects HTTP 501 responses from the metrics API and permanently disables the Monitor page for the session. Fragile because 501 can also indicate transient storage failures, and there is no retry logic.StorageCapabilities— server-reported capabilities injected into the UI at serve time (currently only reportsarchiveStorage). This is the right mechanism but doesn't yet cover metrics storage.These three mechanisms are redundant and sometimes contradictory. A cleaner design uses a single source of truth: the server reports whether metrics storage is available via
StorageCapabilities, and the UI trusts that.Target Design
StorageCapabilitieswithmetricsStorage: boolean— the server sets this based on its configuration.storageCapabilities.metricsStorageinstead ofmonitor.menuEnabled.isATMActivatedfrom the UI state — no more runtime 501 probing to detect feature availability.