Surface active bandwidth limits and stale-cap saturation in the UI #13

Merged

ClaudiuSchuster merged 1 commit from oss-oo/app-polish-rt20261009 into main

2026-10-09 05:33:59 +00:00

ClaudiuSchuster commented

2026-10-09 05:32:24 +00:00

Owner

What this changes

Four bandwidth-clarity changes following the download-limit investigation
dossier (station incident 2026-10-08: a stale upload-only cap was misread as
"download limit degrades upload" because the effective limits were invisible
where the owner was looking):

Stale-cap notice — when an upload limit is active and measured upload
throughput has saturated it for ≥10 consecutive minutes at ≥95% of the
configured cap (evaluated from the persisted graph history samples, with a

60 s sample-gap guard and a freshness bound), a dismissible informational
notice appears in the transfers area stating the effective cap and offering
"Change limits …". One persistent dismiss per policy value, reset when the
policy changes. No desktop notification. EN + DE.
Active limits visible — the Transfers page leads with a "Transfer
limits" card stating the currently effective per-direction limits in all
five states (unavailable / both unlimited / each direction capped), sourced
from the existing bandwidth.live state section and refreshed on the
normal poll cadence. No new settings; bin/pdrive-state is untouched.
Download counter labeling — the download graph title, detail tooltips
and the What's-happening row now state that the process-owned receive
counter includes Proton API overhead, aligning every surface with the graph
source disclosure. EN + DE.
Dead-placeholder cleanup — the unreachable "Collecting traffic history
since {time}" branch (validator F2 from the time-range round) is removed
honestly: dead branch, attribute, EN + DE strings and test rows deleted
with zero leftovers; the reachable timestamp-less placeholder stays and
the previously-wrong OPERATIONS.md sentence now matches reality.

docs/OPERATIONS.md documents the notice and limits line (access path,
meaning, persistence, timing, safety) and the labeling clarification.

Evidence

Independent validation: ACCEPT-WITH-FINDINGS — all four spec items PASS
(threshold logic with boundary tests at 21 samples armed / 20 not, dismiss
persistence proven by a real non-demo subprocess round-trip including
fresh-instance reload, five-state limits card, three-surface labeling
assertions, zero repo-wide placeholder leftovers). Dossier on file in the
release lane round dir.
Gates: make check green (full portable repository suite); the changed
docs/OPERATIONS.md passes prettier@3.5.3 --check; git diff --check
clean; single commit 8cb614d on current main (38b3ca8).
Tests: widget tests cover the saturation window (boundary pinned),
dismissal + reset-on-policy-change, all limits-line states, labeling on all
three surfaces, and the placeholder behavior after cleanup; preference
persistence round-trip extended.

Non-blocking findings (recorded for follow-up rounds)

read_graph_history's first_ms return value is now dead code — candidate
for a later signature simplification.
German test assertions cover a subset of the new strings (spot-check idiom
of the suite); the remaining new strings have verified dict entries.
The notice's "Change limits …" opens the Bandwidth dialog (where limits are
configured), not the Preferences window — conscious, correct interpretation
of the spec's "pointer to Preferences".
The minimum-width test wasn't extended to the new card; its labels wrap
(line_wrap(True) in a never-horizontally-scrolling page) but there is no
dedicated narrow-width assertion.

## What this changes Four bandwidth-clarity changes following the download-limit investigation dossier (station incident 2026-10-08: a stale upload-only cap was misread as "download limit degrades upload" because the effective limits were invisible where the owner was looking): 1. **Stale-cap notice** — when an upload limit is active and measured upload throughput has saturated it for ≥10 consecutive minutes at ≥95% of the configured cap (evaluated from the persisted graph history samples, with a >60 s sample-gap guard and a freshness bound), a dismissible informational notice appears in the transfers area stating the effective cap and offering "Change limits …". One persistent dismiss per policy value, reset when the policy changes. No desktop notification. EN + DE. 2. **Active limits visible** — the Transfers page leads with a "Transfer limits" card stating the currently effective per-direction limits in all five states (unavailable / both unlimited / each direction capped), sourced from the existing `bandwidth.live` state section and refreshed on the normal poll cadence. No new settings; `bin/pdrive-state` is untouched. 3. **Download counter labeling** — the download graph title, detail tooltips and the What's-happening row now state that the process-owned receive counter includes Proton API overhead, aligning every surface with the graph source disclosure. EN + DE. 4. **Dead-placeholder cleanup** — the unreachable "Collecting traffic history since {time}" branch (validator F2 from the time-range round) is removed honestly: dead branch, attribute, EN + DE strings and test rows deleted with zero leftovers; the reachable timestamp-less placeholder stays and the previously-wrong OPERATIONS.md sentence now matches reality. `docs/OPERATIONS.md` documents the notice and limits line (access path, meaning, persistence, timing, safety) and the labeling clarification. ## Evidence - **Independent validation:** ACCEPT-WITH-FINDINGS — all four spec items PASS (threshold logic with boundary tests at 21 samples armed / 20 not, dismiss persistence proven by a real non-demo subprocess round-trip including fresh-instance reload, five-state limits card, three-surface labeling assertions, zero repo-wide placeholder leftovers). Dossier on file in the release lane round dir. - **Gates:** `make check` green (full portable repository suite); the changed `docs/OPERATIONS.md` passes `prettier@3.5.3 --check`; `git diff --check` clean; single commit `8cb614d` on current `main` (`38b3ca8`). - **Tests:** widget tests cover the saturation window (boundary pinned), dismissal + reset-on-policy-change, all limits-line states, labeling on all three surfaces, and the placeholder behavior after cleanup; preference persistence round-trip extended. ## Non-blocking findings (recorded for follow-up rounds) - `read_graph_history`'s `first_ms` return value is now dead code — candidate for a later signature simplification. - German test assertions cover a subset of the new strings (spot-check idiom of the suite); the remaining new strings have verified dict entries. - The notice's "Change limits …" opens the Bandwidth dialog (where limits are configured), not the Preferences window — conscious, correct interpretation of the spec's "pointer to Preferences". - The minimum-width test wasn't extended to the new card; its labels wrap (`line_wrap(True)` in a never-horizontally-scrolling page) but there is no dedicated narrow-width assertion.

ClaudiuSchuster added 1 commit

2026-10-09 05:32:24 +00:00

Surface active bandwidth limits and stale-cap saturation in the UI

Checks / Functional checks (pull_request) Successful in 1m23s

Details Explain this check

8cb614dbe6

Add a Transfer limits card to the transfers page stating the effective
per-direction limits from the live data-bandwidth state, with a dismissible
informational notice when uploads ride an active cap for ten consecutive
minutes at 95% or more of it (one persisted dismissal per policy value,
reset on policy change, no desktop notification). Label every download
receive-rate panel with the Proton API overhead disclosure, and drop the
unreachable timestamped traffic-history placeholder together with its
write-only start-timestamp state.

ClaudiuSchuster merged commit fceff2c100 into main

2026-10-09 05:33:59 +00:00

ClaudiuSchuster deleted branch oss-oo/app-polish-rt20261009

2026-10-09 05:33:59 +00:00

ClaudiuSchuster referenced this pull request from a commit

2026-10-09 05:34:00 +00:00

Surface active bandwidth limits and stale-cap saturation in the UI (#13)

ClaudiuSchuster referenced this pull request

2026-10-09 05:45:12 +00:00

Prepare PDrive 0.9.5 #14