Telemetry Freshness Policy #39

New issue

Open

opened 2026-03-16 05:34:46 +03:00 by skobkin · 1 comment

skobkin commented

2026-03-16 05:34:46 +03:00

Owner

This is a follow-up for #33

Summary

Define one shared telemetry freshness policy for the frontend instead of letting individual components invent local rules.

The current battery-popup PR is a good example of the problem:

the map popup introduces its own hard-coded 3 hour freshness threshold
the Nodes page still shows older telemetry
freshness behavior is inconsistent between surfaces
the threshold lives only in frontend map code, with no product-level definition

Goal

Keep the UI showing the freshest available data without adding avoidable backend or network load, while staying consistent across components.

Proposal

Add a telemetry freshness threshold to backend bootstrap metadata.
Suggested shape:
- meta.telemetry.freshness_threshold
- duration string, same style as other config-backed durations
Use that bootstrap value on the frontend as the single source of truth.
- no component-local hard-coded thresholds
- no popup-local business rules
Add one shared frontend helper for telemetry freshness decisions.
Example responsibilities:
- isTelemetryFresh(snapshot, threshold)
- telemetryAge(snapshot)
- optional telemetryFreshnessLabel(snapshot, threshold)
Apply the helper consistently across UI surfaces.
Candidate surfaces:
- map popup
- node details page
- any future compact node cards / tables / badges

Suggested UX Direction

Preferred default:

show the latest available telemetry by default
do not silently hide old values in one surface but not another
when freshness matters, mark stale values explicitly instead of disappearing them

Two viable product directions:

Compact views show only fresh telemetry; detailed views show stale telemetry with explicit stale labeling.
All views show latest telemetry, but stale values are visibly marked everywhere.

Either direction is acceptable if it is shared and intentional. The important part is that it should be one app-wide rule.

Non-Goals

Do not add periodic polling timers just to age out displayed telemetry.
Do not fetch extra backend data solely to keep freshness labels exact in real time.
Do not implement this as a map-only rule.

Implementation Notes

Backend already serves bootstrap metadata; this is the right place to pass the threshold.
The threshold can be config-backed later if needed, but the frontend should only consume the bootstrap value.
Normal rerenders from bootstrap data, websocket updates, and user navigation should be enough for most UX needs.
If exact expiry while a panel stays open is ever required, prefer a one-shot timeout scheduled for the relevant stale moment instead of a repeating polling loop.

Acceptance Criteria

A telemetry freshness threshold is exposed in bootstrap metadata.
Frontend freshness decisions use one shared helper.
Map popup and Nodes page use the same freshness policy.
No component contains its own hard-coded telemetry freshness constant.
No repeating timer is introduced solely for telemetry staleness display.

This is a follow-up for #33 ## Summary Define one shared telemetry freshness policy for the frontend instead of letting individual components invent local rules. The current battery-popup PR is a good example of the problem: - the map popup introduces its own hard-coded 3 hour freshness threshold - the Nodes page still shows older telemetry - freshness behavior is inconsistent between surfaces - the threshold lives only in frontend map code, with no product-level definition ## Goal Keep the UI showing the freshest available data without adding avoidable backend or network load, while staying consistent across components. ## Proposal 1. Add a telemetry freshness threshold to backend bootstrap metadata. Suggested shape: - `meta.telemetry.freshness_threshold` - duration string, same style as other config-backed durations 2. Use that bootstrap value on the frontend as the single source of truth. - no component-local hard-coded thresholds - no popup-local business rules 3. Add one shared frontend helper for telemetry freshness decisions. Example responsibilities: - `isTelemetryFresh(snapshot, threshold)` - `telemetryAge(snapshot)` - optional `telemetryFreshnessLabel(snapshot, threshold)` 4. Apply the helper consistently across UI surfaces. Candidate surfaces: - map popup - node details page - any future compact node cards / tables / badges ## Suggested UX Direction Preferred default: - show the latest available telemetry by default - do not silently hide old values in one surface but not another - when freshness matters, mark stale values explicitly instead of disappearing them Two viable product directions: 1. Compact views show only fresh telemetry; detailed views show stale telemetry with explicit stale labeling. 2. All views show latest telemetry, but stale values are visibly marked everywhere. Either direction is acceptable if it is shared and intentional. The important part is that it should be one app-wide rule. ## Non-Goals - Do not add periodic polling timers just to age out displayed telemetry. - Do not fetch extra backend data solely to keep freshness labels exact in real time. - Do not implement this as a map-only rule. ## Implementation Notes - Backend already serves bootstrap metadata; this is the right place to pass the threshold. - The threshold can be config-backed later if needed, but the frontend should only consume the bootstrap value. - Normal rerenders from bootstrap data, websocket updates, and user navigation should be enough for most UX needs. - If exact expiry while a panel stays open is ever required, prefer a one-shot timeout scheduled for the relevant stale moment instead of a repeating polling loop. ## Acceptance Criteria - A telemetry freshness threshold is exposed in bootstrap metadata. - Frontend freshness decisions use one shared helper. - Map popup and Nodes page use the same freshness policy. - No component contains its own hard-coded telemetry freshness constant. - No repeating timer is introduced solely for telemetry staleness display.

skobkin added the

enhancement

label

2026-03-16 05:34:46 +03:00

skobkin self-assigned this

2026-03-16 05:34:46 +03:00

skobkin commented

2026-03-16 05:34:57 +03:00

Author

Owner

CC @notfence.

skobkin referenced this issue