mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-11 14:00:29 +00:00
e8455e84b7
Canonical IDs for merged-source hosts (PVE node + pulse-agent) were minted from whichever identity keys the creating record happened to carry: the agent record knows the machine ID, the Proxmox node record only knows cluster+hostname. The registry rebuilds from scratch every tick, so a boot window where the agent had not checked in yet minted a cluster-keyed ID (agent-7a62... for delly) while steady state minted a machine-keyed one (agent-bdd4...). Every restart re-ran the race, fragmenting the resource_changes journal into per-boot eras (9.4k vs 6.1k rows for the same host) and silently truncating report availability and UI timelines. Fix, in the layer that owns identity: - Persist identity pins (canonical_id <-> machine_id/dmi/cluster/hostname) in the previously schema-only resource_identities table, written by the store-backed registry after monitor-adapter rebuilds, diff-aware so steady-state ticks cost no writes. - Complete weak incoming identities from the pins before matching and ID derivation, so a node-only boot window derives the same machine-keyed canonical ID as steady state. Derivation itself is unchanged; ephemeral nil-store registries behave exactly as before. - Expand change-journal reads (Get/Count families, SQLite and memory) to the full era set recomputed from the pinned identity keys, healing historical journals at query time with no row migration. Reads keyed by a stale era ID resolve to the same merged timeline. Regression tests cover both ingest orders, restart simulation via the monitor adapter, era ID derivation, and era-merged journal reads on both store implementations. Contracts updated: unified-resources obligation 25 (durable identity pins), monitoring obligation 10 (adapter rebuild persistence).