Skip to content

Add rolling 24-hour Team Runtime usage - #718

Merged
sudomaggie merged 1 commit into
developfrom
dev/team-runtime-rolling-24h
Aug 6, 2026
Merged

Add rolling 24-hour Team Runtime usage#718
sudomaggie merged 1 commit into
developfrom
dev/team-runtime-rolling-24h

Conversation

@Harry19081

Copy link
Copy Markdown
Member

Problem

Team Runtime can show UTC-day totals but cannot render a true rolling 24-hour usage chart or per-member 24-hour comparison. Re-querying each member's local history from the viewer is impossible, and adding another scheduler scan would increase idle I/O.

Solution

Derive a rolling headline and hourly series inside the existing bounded Rust daily-rollup scan, serialize it through the existing Tauri result, and attach it to the scheduler's existing status heartbeat. The cloud status field is additive and optional for older peers, trends are capped at 25 points, and the entire status remains under the existing 8 KiB limit by dropping only the additive snapshot near the cap. Team Runtime aggregates the bounded peer snapshots for its 24-hour chart and lets member drilldowns switch between the inline 24-hour view and existing daily ranges.

Potential risks

Peers on older builds omit the snapshot and appear with an empty 24-hour state until upgraded. Unusually large status metadata can intentionally drop the snapshot while preserving the heartbeat and lifetime census. The local Tauri result gains a required field, but frontend and backend ship together; the cloud wire addition remains optional and needs no schema migration. No CPU or wall-time improvement claim is made because runtime profiling was not performed; the implementation is structurally bounded and reuses the existing scan.

Architecture audit

Covered all 10 architecture layers. Storage schema and identity are unchanged; aggregation ownership remains in orgtrack_core; camelCase serialization and Zod parsing are explicit; the local result has construction/serialization parity; the cloud protocol evolves additively; the rolling window is [end - 24h, end] with hourly bucketing; and old/malformed peer payloads degrade to an absent snapshot. No naming or control-flow sweep candidate was found outside this feature.

Performance guard

Verdict: pass. Active/visible and active/hidden operation reuse the existing scheduler cadence and one bounded database scan; idle operation adds no timer, poll, subscription, or cache; repeated panel open/close creates no retained work; multi-instance behavior is unchanged; restart/cold-start behavior accepts peers without the new field. Memory and payload growth are capped by 25 hourly points, the fixed usage-bucket count, and the 8 KiB status limit. No additional I/O pass or unbounded loop was introduced.

UI audit

Frontend UI audit: 0 fixes, 4 keep-with-reason decisions, and no abstraction or sweep candidate. The report is included at docs/frontend-ui-audit-2026-08-06/RuntimeUsageCharts.md.

Verification

  • Vitest for member-runtime client, scheduler, Team Runtime panel, and runtime data — passed (65 tests across 4 files).
  • cargo test -p orgtrack_core daily_rollup_ — passed (6 tests; 546 filtered out).
  • cargo clippy -p orgtrack_core --lib -- -D warnings — passed.
  • rustfmt --edition 2021 --check on the 4 changed Rust files — passed. Full cargo fmt --all --check was not used as evidence because it reports unrelated pre-existing formatting drift elsewhere in the workspace.
  • ESLint on the 11 changed TypeScript/TSX implementation and test files — passed after formatting correction.
  • pnpm typecheck — passed.
  • Manual desktop verification was not run because local UI control was not authorized for this task.

@Harry19081
Harry19081 marked this pull request as ready for review August 6, 2026 13:00
@sudomaggie
sudomaggie merged commit 7d4e773 into develop Aug 6, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants