Repository navigation
bug: safely enforce MacTrack site-name uniqueness #360
Description
Activity
Update from #357 review: the Default-site creation path now uses
INSERT IGNOREwith fixedsite_id = 1, and its Docker race assigns distinct advisory-lock namespaces to all eight workers. That removes advisory-lock dependence for the Default-row invariant on both MariaDB and MySQL.This issue remains open for the broader migration problem: safely reconciling and preventing duplicate custom site names without losing device relationships or operator-authored metadata.
Further #357 review found that fixing Default to
site_id = 1is unsafe: site deletion currently leavesmac_track_arpandmac_track_dot1xrows behind, so reusing ID 1 could misattribute orphaned history to the new Default site. That approach was reverted.#357 retains the single-primary advisory-lock improvement and now fails CLI installs non-zero plus retries from the poller. This issue remains the place to design topology-independent uniqueness together with legacy duplicate reconciliation and orphan cleanup.
- added a commit that references this issue
on Sep 20, 2026
Problem
mac_track_siteshas only a primary key onsite_id, so duplicate site names—including duplicateDefaultrows—are structurally possible. The Default-site repair in #357 uses a database-scoped advisory lock and a conditional insert, which is safe on a single database server but is not a substitute for a unique constraint in proxied or multi-primary deployments.Adding a unique index directly in the 1.2 release fix is unsafe because existing installations may already contain duplicate custom or Default names and their references must be reconciled deliberately.
Required validation
Relationships
Found during review of #357. Coordinate with the broader schema work in #104 and the legacy migration defect in #359.