Board column tag filter has no effect on displayed sessions

[xcom923]

Summary

Selecting tags in the board-view column filter popover does not filter the session list. The column continues to display all sessions regardless of which tags are selected.

Steps to Reproduce

1. Open the Sessions page in board view (multiple columns visible).
2. Click the tag/filter icon on a column header to open the COLUMN FILTER popover.
3. Select one or more tags from the list (e.g. "Jira", "Alert").
4. Close the popover.

Expected: The column shows only sessions tagged with the selected tag(s), respecting the mode (any/all/none).

Actual: The column still shows all sessions (same count as "ALL SESSIONS"). The filter selection has no visible effect on which sessions appear.

Observations from source

The filtering logic in ChatSidebar.tsx looks architecturally correct:

• columnMatches() (~L1288) checks col.tag_ids and returns true (match-all) when tag_ids is empty.
• onToggleTag (~L3360) calls updateColumnMutation.mutate({ id: col.id, body: { tag_ids: nextIds } }).
• The mutation hits api.updateTagColumn(id, body).

The likely failure point is either:

• The mutation completes but the column's tag_ids in the reactive state doesn't update (stale closure or missing query invalidation).
• The column data refetched after mutation still has an empty tag_ids array (backend doesn't persist the update for non-board columns).

Context

• Possibly related to Board view: global session filters (Unread/Running/Pinned/Recent) have no visible effect #739 (global session filters have no visible effect in board view), though that issue covers a different filter mechanism (Unread/Running/Pinned toggles).
• The search text input at the top of the popover also appears non-functional (typing doesn't narrow the tag list), though that may be a separate narrowing-only UX issue vs. the core "filter not applied" bug.

Environment

• KiroCrew dashboard, macOS
• Board view with user-created columns

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: Your reading of the frontend is right, and it is not where the selection is lost — columnMatches (ChatSidebar.tsx:1448) is correct, onToggleTag does fire the mutation with the next id list (line 3597), and updateColumnMutation does invalidate the ['tag-columns'] query on success. The write path is the suspect: _normalize_column filters the incoming ids against the tag registry — cleaned["tag_ids"] = [str(t) for t in tag_ids if isinstance(t, str) and t in valid_ids] where valid_ids = {t.get("id") for t in state._tags} (chat_tags.py:431-437) — and any id it does not recognize is dropped silently, with the PATCH still returning 200. A column that lands back on tag_ids: [] then matches every session by design (line 1451 returns true for an empty filter), which is precisely the reported "same count as ALL SESSIONS". Starting an automated fix: reproduce with a failing test that PATCHes a real selected tag id, establish whether the ids the popover sends match state._tags, fix the mismatch at its source, and make the unknown-id case fail loudly (400) instead of silently degrading to match-all. Note this is a different surface from #739 (global board filters), so both stay open. This issue is now claimed by bolichen97's instance.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: Fix is up — #2568

Root cause confirmed empirically: the reported happy path (valid tag id → PATCH → persist → render) works on main; the failure is the write path's silent drop — an id the vocabulary doesn't hold at PATCH time (stale popover cache after a cross-window tag delete, or a dangling id left by a crash mid-tag-delete) was quietly stripped while the PATCH still returned 200, landing the column on tag_ids: [] = match-all, i.e. the exact 'same count as ALL SESSIONS' you saw. The PR makes that path loud (400 + invalid_column_payload), self-healing in the popover (error re-syncs the tag/column caches), and self-repairing at load (dangling ids pruned). The 'search input' at the top of the popover is actually the column-rename field — a separate UX nit, not part of this fix.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: #2568 is review-ready — 51/51 checks green on 61000ea, readiness:passed, zero fix iterations. Awaiting human merge.