m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

/views/any: none of the filters work (regression from today's filter-bar churn) #115

New Issue
Open
opened 2026-05-25 15:09:52 +00:00 by mAi · 0 comments
mAi commented 2026-05-25 15:09:52 +00:00
Collaborator
Copy Link

m's report (2026-05-25 17:09)

https://paliad.de/views/any

None of the filters on this custom view seem to work.

Likely regression source

Today's merges touched the filter-bar / view_service heavily:

  • t-paliad-249 (#80 inbox overhaul) — InboxSystemView extension + new axes (unread_only, inbox_focus) + RowActionInbox dispatch in shape-list.ts
  • t-paliad-248 (#79 date-range picker) — replaced time axis stub with mountDateRangePicker
  • t-paliad-278 (#110 picker 3-column layout) — rewrote date-range-picker.ts internals
  • t-paliad-265 (#96 event-card choices) — added project_event_choices URL state to verfahrensablauf (not /views directly, but used the URL plumbing)
  • t-paliad-279 (#111 verfahrensablauf reorder) — touched the verfahrensablauf form but reads from filter URL

Something in this chain broke /views/any's filter pipeline. Likely candidates:

  1. render_spec.go / system_views.go — the any system view's predicate may have been clobbered when icarus extended InboxSystemView (they share render-spec scaffolding).
  2. filter_spec.go — atlas's TimeSpec extension or icarus's unread_only axis may have changed the predicate translation rules.
  3. url-codec.ts — both icarus + atlas modified it; an off-by-one in axis serialization could blank every filter from the URL on read.
  4. shape-list.ts RowActionInbox dispatch — if the any view falls through to a missing branch, the list may render with no rows OR no filter chips active.
  5. Mismatch between BarState shape (frontend) and FilterSpec parsing (backend) — added axes (unread_only, inbox_focus) may be required on every view now, breaking the any view's bare-bones spec.

What to do

  1. Reproduce live at https://paliad.de/views/any on a real test project — click each filter chip, observe what happens (does the URL update? Does the rendered list change? Does the network call to /api/views/any/run succeed?).
  2. Diagnose with browser DevTools — Network tab to see if the backend gets the filter params, Console to see if there's a JS error.
  3. Bisect by reverting today's filter-touching merges one by one in a local branch if the cause isn't obvious.
  4. Fix the smallest correct issue. Add a regression test against /views/any rendering with each filter active.

Files most likely touched

  • internal/services/view_service.go — any view's predicate handling
  • internal/services/system_views.go — any SystemView's spec
  • internal/services/filter_spec.go — predicate translation
  • frontend/src/client/views/shape-list.ts — render dispatch
  • frontend/src/client/filter-bar/url-codec.ts — URL ↔ BarState serialization
  • frontend/src/client/filter-bar/axes.ts — axis render dispatch
  • frontend/src/views.tsx / frontend/src/client/views.ts — the page that hosts the bar

Hard rules

  • Don't undo today's feature merges — fix the regression with minimal surgical change.
  • Add a regression test so the /views/any filter pipeline is covered by go test going forward.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/views-any-filters-regression.

Out of scope

  • Redesigning Custom Views.
  • Other system views (focus on /any first; audit other built-in views in the same pass if cheap).
  • Replacing the existing filter-bar component.

Reporting

mai report completed with branch + SHAs + root cause + UX verification: open /views/any → each filter chip changes the rendered list as expected → URL updates → backend call returns filtered rows.

## m's report (2026-05-25 17:09) > https://paliad.de/views/any > > None of the filters on this custom view seem to work. ## Likely regression source Today's merges touched the filter-bar / view_service heavily: - t-paliad-249 (#80 inbox overhaul) — InboxSystemView extension + new axes (`unread_only`, `inbox_focus`) + RowActionInbox dispatch in shape-list.ts - t-paliad-248 (#79 date-range picker) — replaced `time` axis stub with `mountDateRangePicker` - t-paliad-278 (#110 picker 3-column layout) — rewrote date-range-picker.ts internals - t-paliad-265 (#96 event-card choices) — added project_event_choices URL state to verfahrensablauf (not /views directly, but used the URL plumbing) - t-paliad-279 (#111 verfahrensablauf reorder) — touched the verfahrensablauf form but reads from filter URL Something in this chain broke `/views/any`'s filter pipeline. Likely candidates: 1. **`render_spec.go` / `system_views.go`** — the `any` system view's predicate may have been clobbered when icarus extended InboxSystemView (they share render-spec scaffolding). 2. **`filter_spec.go`** — atlas's TimeSpec extension or icarus's unread_only axis may have changed the predicate translation rules. 3. **`url-codec.ts`** — both icarus + atlas modified it; an off-by-one in axis serialization could blank every filter from the URL on read. 4. **`shape-list.ts` RowActionInbox dispatch** — if the `any` view falls through to a missing branch, the list may render with no rows OR no filter chips active. 5. **Mismatch between BarState shape (frontend) and FilterSpec parsing (backend)** — added axes (`unread_only`, `inbox_focus`) may be required on every view now, breaking the `any` view's bare-bones spec. ## What to do 1. **Reproduce live** at `https://paliad.de/views/any` on a real test project — click each filter chip, observe what happens (does the URL update? Does the rendered list change? Does the network call to `/api/views/any/run` succeed?). 2. **Diagnose** with browser DevTools — Network tab to see if the backend gets the filter params, Console to see if there's a JS error. 3. **Bisect** by reverting today's filter-touching merges one by one in a local branch if the cause isn't obvious. 4. **Fix the smallest correct issue**. Add a regression test against `/views/any` rendering with each filter active. ## Files most likely touched - `internal/services/view_service.go` — `any` view's predicate handling - `internal/services/system_views.go` — `any` SystemView's spec - `internal/services/filter_spec.go` — predicate translation - `frontend/src/client/views/shape-list.ts` — render dispatch - `frontend/src/client/filter-bar/url-codec.ts` — URL ↔ BarState serialization - `frontend/src/client/filter-bar/axes.ts` — axis render dispatch - `frontend/src/views.tsx` / `frontend/src/client/views.ts` — the page that hosts the bar ## Hard rules - **Don't undo today's feature merges** — fix the regression with minimal surgical change. - **Add a regression test** so the `/views/any` filter pipeline is covered by `go test` going forward. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/views-any-filters-regression`. ## Out of scope - Redesigning Custom Views. - Other system views (focus on `/any` first; audit other built-in views in the same pass if cheap). - Replacing the existing filter-bar component. ## Reporting `mai report completed` with branch + SHAs + root cause + UX verification: open /views/any → each filter chip changes the rendered list as expected → URL updates → backend call returns filtered rows.
mAi self-assigned this 2026-05-25 15:09:52 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#115
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?