Multi-site: rack list building filter + re-enable /buildings/:id View racks (#274)

[flesher]

Summary

Wires the ?building=<id> URL contract through the rack list and re-enables the View racks affordance on /buildings/:id (was disabled in #269 pending this work). Backend building_ids / include_no_building filter on ListDeviceSetsRequest already shipped in #229 / #198; this PR is the FE side.

Closes #274.

Changes

• RacksPage.tsx — parses ?building=<id> from URL (accepts repeated-key + legacy comma-joined forms, matches filterUrlParams.ts), loads all buildings via listAllBuildings, registers a Building filter in FilterChipsBar with the building name. URL is the source of truth — back/forward navigation and chip removal stay in sync.
• useDeviceSets.ts / useDeviceSetListState.ts — thread buildingIds through listRacks → ListDeviceSets.
• BuildingPageHeader.tsx — replaces the disabled View racks button + tooltip with <Link to="/racks?building=…">. Mirrors the existing View miners URL contract.
• MinerList.handleServerFilter (drive-by, fixes regression surfaced by this PR's deep-link) — also translates dropdownFilters.building → MinerListFilter.buildingIds. Without this, the building filter was silently dropped on mount and the URL was rewritten without ?building=. savedViews.FILTER_AND_SORT_KEYS now includes "building" so building-scoped URLs canonicalize as filtered state (instead of "All miners").

Deferred

• Miner list building chip — name resolution. The miner list now honors ?building=<id> end-to-end, but the FilterChipsBar dropdown sources don't include a Building entry, so the chip renders the raw id (10) rather than the building name (Bldg-A-23924) and there's no UI affordance to clear it. Punted to Multi-site — Phase 1b: miner/rack list active-site consumption #202 (Phase 1b miner/rack list active-site consumption) since the fix needs listAllBuildings plumbed into Fleet.tsx + a new DropdownFilterItem in MinerList.tsx — naturally overlaps with the site-picker consumption work tracked there. Tracking comment: Multi-site — Phase 1b: miner/rack list active-site consumption #202 (comment)

Test plan

• On /buildings/:id, click View racks — lands on /racks?building=<id>.
• Building chip on /racks renders the building name, removable like other filters; clearing the chip strips ?building= from the URL.
• Back/forward navigation keeps the chip and list in sync with the URL.
• On /buildings/:id, click View miners — lands on /miners?building=<id> and the URL stays intact (no on-mount strip).
• just lint, tsc --noEmit, vitest run (full client suite), Go tests for internal/handlers/deviceset + internal/domain/collection all pass locally.

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (2bf18b57c9765ca25a3634b67b225ee1b4b9e91d...1425dabcd852ff993458d9e8a48afe05d902cc58, exact PR three-dot diff)
• Model: gpt-5.5

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: MEDIUM

Findings

[MEDIUM] Miner building filter is applied without a visible filter control

• Category: Frontend
• Location: client/src/protoFleet/features/fleetManagement/components/MinerList/MinerList.tsx:873
• Description: The PR now converts filters.dropdownFilters.building into minerFilter.buildingIds, so /miners?building=<id> becomes an active server-side filter. However, the miner list filter definitions still do not include a building dropdown source, and the shared filter UI only renders chips for configured filter sources. The result is a filtered miner list with no visible Building chip/control.
• Impact: Operators can land on a building-filtered miner list and see/export/act on a subset of miners without an obvious UI indication that the list is constrained.
• Recommendation: Add a Building filter item to the miner list, backed by building options and labels, so URL-driven building filters render as normal chips and can be edited/cleared. Alternatively, defer applying buildingIds until the UI can expose the active filter.

Notes

No auth, SQL, command execution, plugin, infrastructure, protobuf wire-format, or mining pool/payout hijack issues were introduced in the reviewed diff. I did not run tests; this was a scoped diff review of .git/codex-review.diff.

---

_{Generated by Codex Security Review |
Triggered by: @flesher |
Review workflow run}

[Copilot]

Pull request overview

This PR wires the existing ?building=<id> URL filter contract into the racks list, re-enables the “View racks” navigation from /buildings/:id, and ensures the miner list preserves building-scoped deep links by translating the building dropdown filter into MinerListFilter.buildingIds.

Changes:

• Add building-aware rack listing by parsing ?building= on /racks, loading building names for the filter chip, and passing buildingIds through to ListDeviceSets.
• Re-enable /buildings/:id → /racks?building=… navigation via a “View racks” link.
• Fix miner list deep-link canonicalization by mapping dropdownFilters.building → MinerListFilter.buildingIds and whitelisting building in saved-view URL canonicalization.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
client/src/protoFleet/hooks/useDeviceSetListState.ts	Threads optional buildingIds into paginated rack listing requests.
client/src/protoFleet/features/rackManagement/pages/RacksPage.tsx	Parses ?building= from URL, loads building options, and binds a Building filter chip to URL state.
client/src/protoFleet/features/fleetManagement/views/savedViews.ts	Treats building as a canonical filter/sort key so deep links persist as filtered state.
client/src/protoFleet/features/fleetManagement/components/MinerList/MinerList.tsx	Translates building dropdown selections into minerFilter.buildingIds.
client/src/protoFleet/features/buildings/components/BuildingPageHeader.tsx	Re-enables “View racks” navigation using the building URL param.
client/src/protoFleet/api/useDeviceSets.ts	Passes buildingIds through in listRacks requests to the backend.

Comments suppressed due to low confidence (1)

client/src/protoFleet/features/rackManagement/pages/RacksPage.tsx:242

• handleClearFilters calls setBuildingFilter([]) and then immediately resetAndFetch(). Because the building filter is URL-driven and selectedBuildingIdsRef is updated in an effect, this first fetch can still run with the old buildingIds (and then the separate URL-change effect triggers another fetch). This can briefly show stale, still-building-filtered results and does an extra round-trip.

Consider making the clear-all path update the buildingIds ref synchronously (or set it to [] before fetching), or remove the direct resetAndFetch() here and instead have a single refetch effect that responds to all filter changes (building/zone/issues) so the fetch always uses the latest filter state once per change.

  const handleClearFilters = useCallback(() => {
    setSelectedZones([]);
    selectedZonesRef.current = [];
    setSelectedIssues([]);
    selectedIssuesRef.current = [];
    setBuildingFilter([]);
    resetAndFetch();
  }, [resetAndFetch, selectedIssuesRef, selectedZonesRef, setBuildingFilter]);

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b10cdd3ca8

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[flesher]

Review polish — 1425dab

Addressed three of the four review findings; filed #291 for the fourth.

Finding	Source	Action
Wrong null state for empty-result building deep links	Codex P2 (inline)	Fixed. hasRacks now short-circuits on hasActiveFilters so the filtered-empty branch (chip + NoFilterResultsEmptyState) wins.
handleClearFilters double-fetches when building was active	Copilot (suppressed)	Fixed. Snapshot hadBuildingFilter up front; skip the explicit resetAndFetch when the URL-change effect will handle the refetch.
No FE tests for the URL parse	Copilot (inline) + me	Fixed. Extracted parseBuildingIdsFromParams + BUILDING_URL_PARAM to rackManagement/utils/buildingFilterUrl.ts and added 13 vitest cases covering repeated keys, legacy comma-joined, mixed forms, invalid input, ordering, large bigints.
<Link><Button/></Link> nests interactive elements	Copilot (inline)	Filed as #291. Pre-existing pattern on View miners; #285 added View racks with the same shape. Better to fix both instances + audit other call sites in one focused PR than mix scope here.

Deferred chip-name resolution for the miner-list still tracked on #202.

Local verification: just format, just lint, tsc --noEmit, vitest for the new util + adjacent suites all green.

[negarn]

looks good! just wondering if you meant to include the server/ changes in this PR

[flesher]

ya i think that dependency tidying was missed in a previous PR so i just included it.