Stale Registries Need Local Authority
Stale registries need local authority
External registries are snapshots. They may lag, omit a live resource, retain stale entries, or describe the resource from a different authority than the one actually operating it.
If the local process owns a live resource, that local ownership is evidence too. Do not blindly let a remote registry erase local truth.
The rule
Track source and freshness for registry-derived state.
When a local subsystem owns a resource, surface that owned state alongside the registry snapshot, with clear identity and validity. Use the registry to reconcile, not to decide whether the local resource exists.
Spotuify example
Spotuify registers an embedded librespot Spotify Connect device inside the daemon. Spotify's /v1/me/player/devices list can lag or retain stale namesakes from previous daemon runs. The daemon can derive its own device id from the registration name and knows whether its player is connected.
So the device list should include the daemon-owned connected device even if the cached Spotify device list has not caught up. The remote registry remains useful, but it is not the only authority.
Design smell
If a UI says "resource missing" while the local owner is actively running that resource, the system probably collapsed two authorities into one field.
Separate them:
- registry snapshot
- local owner state
- freshness/validity interval
- reconciliation result
Where this generalizes
- Language servers: a project index can be live even before the editor's file list refreshes.
- Deployments: a local deploy process can own a rollout before the cloud dashboard reflects it.
- Debuggers: a session can be attached even if a process registry is stale.
- Caches: a warmed artifact can be valid locally while the upstream list is behind.