refactor(telemetry): recent_activity exclusion filtering is duplicated across backend and frontend #42

New issue

Closed

opened 2026-09-21 18:18:32 +00:00 by gabogg · 0 comments

gabogg commented

2026-09-21 18:18:32 +00:00

Owner

Context

Raised in the round-1 and round-2 reviews of #37 and left standing at merge. Non-blocking.

Problem

Excluded doors are filtered out of the activity stream twice, independently:

Backend — app/services/door_service.py:1259-1268 filters recent_cycles and stamps exclude_from_rankings onto each cycle dict.
Frontend — app/static/js/src/ui/command_deck_adapter.js:527-539 builds a Set of excluded door codes from snapshot.doors and re-filters, checking both the cycle's own flag and the door-code match.

The frontend cross-check was added deliberately in #37 so that an unstamped or legacy cycle payload cannot leak an excluded door, which is a reasonable defensive position. The result is still two implementations of one rule that must agree, in two languages, with no shared test pinning them together.

Why it matters

The predicate has already drifted once: is_door_excluded in Python and isDoorExcluded in JS diverged on flag precedence and had to be re-aligned mid-review in #37. Two filter sites is the same failure shape one level up.

Proposed direction

Decide which layer owns the rule and make the other one thin:

If the backend is authoritative, the frontend check becomes an assertion or a dev-mode warning rather than a second filter.
If the frontend must stay defensive (mixed-version clients, cached payloads), document that explicitly in CONTEXT.md and add a test that feeds an unstamped cycle through the adapter.

Acceptance criteria

One documented owner for activity-stream exclusion filtering.
Either the redundant filter is removed, or the defensive one is covered by a test that proves what it defends against.

## Context Raised in the round-1 and round-2 reviews of #37 and left standing at merge. Non-blocking. ## Problem Excluded doors are filtered out of the activity stream twice, independently: - Backend — `app/services/door_service.py:1259-1268` filters `recent_cycles` and stamps `exclude_from_rankings` onto each cycle dict. - Frontend — `app/static/js/src/ui/command_deck_adapter.js:527-539` builds a `Set` of excluded door codes from `snapshot.doors` and re-filters, checking both the cycle's own flag and the door-code match. The frontend cross-check was added deliberately in #37 so that an unstamped or legacy cycle payload cannot leak an excluded door, which is a reasonable defensive position. The result is still two implementations of one rule that must agree, in two languages, with no shared test pinning them together. ## Why it matters The predicate has already drifted once: `is_door_excluded` in Python and `isDoorExcluded` in JS diverged on flag precedence and had to be re-aligned mid-review in #37. Two filter sites is the same failure shape one level up. ## Proposed direction Decide which layer owns the rule and make the other one thin: - If the backend is authoritative, the frontend check becomes an assertion or a dev-mode warning rather than a second filter. - If the frontend must stay defensive (mixed-version clients, cached payloads), document that explicitly in `CONTEXT.md` and add a test that feeds an unstamped cycle through the adapter. ## Acceptance criteria - [ ] One documented owner for activity-stream exclusion filtering. - [ ] Either the redundant filter is removed, or the defensive one is covered by a test that proves what it defends against.

gabogg added the

needs-triage

label

2026-09-21 18:18:32 +00:00

gabogg referenced this issue from a commit

2026-09-21 18:28:48 +00:00

refactor(telemetry): document activity stream exclusion ownership and add defensive test (#42)

gabogg referenced this issue from a pull request that will close it,

2026-09-21 18:28:58 +00:00

refactor(telemetry): defensive activity stream exclusion filtering (#42) #44

gabogg referenced this issue

2026-09-21 18:36:19 +00:00