block / block/proto-fleet

Infra device placement parity: real site/building FKs so infra behaves like miners

Open
#748 0 comments 0 reactions 0 assignees View on GitHub
enhancement multi-site server
Dominant language
Go
Stars
55
Forks
16
Avg merge
1d 22h
Merged PRs (30d)
87

Description

## Summary

Give `infrastructure_device` real `site_id` / `building_id` foreign keys — matching the placement model of `device` (miners) — instead of the current mandatory `site_id` + free-form `building_name` string.

## Motivation

Surfaced while planning #745 (Import/Export Site Map CSV). Infra devices currently model placement asymmetrically from miners:

- `infrastructure_device.site_id` is `NOT NULL` (a fan must always belong to a site — there's no "unassigned" bucket).
- `building_name` is a **free-form `VARCHAR` string**, not a foreign key to `building`. It isn't validated against the buildings table and can drift from real building names.
- There is no rack concept for infra (fine, expected).

Because of this, the #745 CSV importer had to make infra a special case:

- Infra rows can update placement (site + building) but the uniform **"omission = remove"** policy that applies to sites/buildings/racks/miners **can't apply to infra** — the only removable attribute is `building_name` (site can't be nulled, device can't be deleted in v1), which isn't a meaningful destructive operation. So infra is **exempt** from omission-removal in #745 v1.

## Proposal

- Add `building_id BIGINT NULL` FK to `infrastructure_device` (composite `(building_id, org_id)` → `building`, consistent with `device`).
- Decide whether `site_id` should become nullable so a fan can be genuinely "unassigned" like a miner, or stay mandatory (needs product input — is a site-less fan meaningful?).
- Migrate existing `building_name` values → resolve to `building_id` where a matching building exists under the site; keep `building_name` as a transitional/denormalized display field or drop it.
- Update the infra service/handlers, proto, and client pickers to use the FK.

## Payoff

Once infra placement matches miners, the #745 importer can **treat infra identically to the other sections** — including the uniform omission-removal policy — and drop the v1 exemption (decision #4 / "Follow-ups" in the #745 plan).

## References

- Plan: `docs/plans/2026-07-14-745-import-export-site-map-csv-plan.md`
- Parent: #745
- Infra foundation: #724

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Contributor guide

Open the contributing guide

Research direction

Start with the infrastructure_device schema and the existing device placement model, then read docs/plans/2026-07-14-745-import-export-site-map-csv-plan.md and the infra foundation from #724. Trace the infra service/handlers, proto, and client pickers that use site and building placement. Done requires a decided site-nullability policy, migrated building references, and consistent FK-based behavior across those surfaces.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.