Background
From the Codex security review on PR #551 (MEDIUM). The "New rack" create flow seeds the new rack with the operator's current miner selection. In all-selection mode this resolves the full fleet set.
Problem
handleCreateNewLaunch in client/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/MinerReparentPicker.tsx (~:688-717) passes the full resolved ids straight into the rack seed:
if (kind === "rack") {
createFlow.launchCreateRack({ minerIds: ids, conflictCount: ... });
}
resolveAllModeIds only caps at MAX_MINERS (~10k), not at rack capacity (12×12 = 144 max). And unlike the other two paths, launchCreateRack in FleetCreateFlowProvider.tsx (~:109-118) applies no cap — launchCreateBuilding/launchCreateSite both call batchCapError(seed) first (~:163), but the rack launch goes straight to openRackSettings(seed). Capacity is only validated later at Save, while MinersPane renders one row per seeded miner.
So a large all-mode selection can render thousands of rows and freeze/severely degrade the browser before the operator ever reaches the save-time capacity guard, even though a rack holds at most 144 slots.
Impact
- Browser freeze / degradation on large fleets when launching "New rack" from an all-mode selection.
Proposed fix
Cap the rack seed before mounting ManageRackModal (mirroring the building/site batchCapError gate):
- Reject selections larger than the chosen rack capacity once settings are picked, or at least larger than the absolute max rack capacity (144), and surface a clear toast.
- Apply the cap in
launchCreateRack and/or handleCreateNewLaunch so MinersPane never renders an unbounded seed.
Notes
🤖 Generated with Claude Code
Background
From the Codex security review on PR #551 (MEDIUM). The "New rack" create flow seeds the new rack with the operator's current miner selection. In all-selection mode this resolves the full fleet set.
Problem
handleCreateNewLaunchinclient/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/MinerReparentPicker.tsx(~:688-717) passes the full resolvedidsstraight into the rack seed:resolveAllModeIdsonly caps atMAX_MINERS(~10k), not at rack capacity (12×12 = 144 max). And unlike the other two paths,launchCreateRackinFleetCreateFlowProvider.tsx(~:109-118) applies no cap —launchCreateBuilding/launchCreateSiteboth callbatchCapError(seed)first (~:163), but the rack launch goes straight toopenRackSettings(seed). Capacity is only validated later at Save, whileMinersPanerenders one row per seeded miner.So a large all-mode selection can render thousands of rows and freeze/severely degrade the browser before the operator ever reaches the save-time capacity guard, even though a rack holds at most 144 slots.
Impact
Proposed fix
Cap the rack seed before mounting
ManageRackModal(mirroring the building/sitebatchCapErrorgate):launchCreateRackand/orhandleCreateNewLaunchsoMinersPanenever renders an unbounded seed.Notes
MinerReparentPicker.tsx:699.🤖 Generated with Claude Code