Ownership trend window is set by snapshot cadence, not elapsed time #14

New issue

Closed

opened 2026-08-27 20:57:39 +02:00 by solvreven · 0 comments

solvreven commented

2026-08-27 20:57:39 +02:00

Owner

ownership_trends(window: int = 2) compares snaps[-2] and snaps[-1] — the
two most recent snapshot directories by position, with no notion of elapsed
time.

So the meaning of "rising"/"falling" depends entirely on how often someone
happened to run snapshot_pit.py. On 2026-08-27 two snapshots were taken 30
minutes apart (before and after a cache rebuild), which collapsed the trend
window from ~2 days to half an hour and made all 616 players read as flat.

It is honestly reported — the UI renders the window via setOwnTrendWindow — so
this is uninformative rather than misleading, and it self-heals at the next
deadline snapshot. But a signal whose meaning is set by an incidental
operational detail will eventually be read as if it meant something fixed.

Suggested fix. Select the earlier snapshot by a minimum elapsed time (e.g.
the most recent one at least 24h older than the latest), fall back to the oldest
available, and report the actual elapsed hours in the meta so the window is
never implied.

Related test note: test_a_missing_measurement_is_none_and_never_zero asserted
on the live cache and went red when the data stopped obliging. It has been
rewritten to force the refusal branch with a synthetic fixture.

`ownership_trends(window: int = 2)` compares `snaps[-2]` and `snaps[-1]` — the two most recent snapshot directories **by position**, with no notion of elapsed time. So the meaning of "rising"/"falling" depends entirely on how often someone happened to run `snapshot_pit.py`. On 2026-08-27 two snapshots were taken 30 minutes apart (before and after a cache rebuild), which collapsed the trend window from ~2 days to half an hour and made all 616 players read as flat. It is honestly reported — the UI renders the window via `setOwnTrendWindow` — so this is uninformative rather than misleading, and it self-heals at the next deadline snapshot. But a signal whose meaning is set by an incidental operational detail will eventually be read as if it meant something fixed. **Suggested fix.** Select the earlier snapshot by a minimum elapsed time (e.g. the most recent one at least 24h older than the latest), fall back to the oldest available, and report the actual elapsed hours in the meta so the window is never implied. Related test note: `test_a_missing_measurement_is_none_and_never_zero` asserted on the live cache and went red when the data stopped obliging. It has been rewritten to force the refusal branch with a synthetic fixture.