Registry Limitations
Understanding the registry state management architecture, limitations, and implemented safety fixes.
Registry State Management
The Registry class uses a single JSON file (~/.localdns/registry.json) for all state storage. Multiple processes (daemon, CLI commands) create separate Registry instances that all read/write to this shared file.
Implemented Safety Fixes
File Locking
Uses proper-lockfile with retry logic (10 retries, 50ms-500ms exponential backoff). Prevents concurrent write conflicts.
Automatic Backups
A backup at ~/.localdns/registry.json.backup is created before every write operation. Automatic restoration on corruption detection.
Optimistic Locking
Re-reads file before write and merges changes at domain level. Last write wins per domain, but no data loss.
File Validation & Recovery
JSON parsing with error handling, automatic fallback to backup on corruption, and empty file detection.
Current Safety Assessment
| Aspect | Status | Notes |
|---|---|---|
| Concurrent Writes | Safe | File locking prevents conflicts |
| Atomic Operations | Safe | Lock ensures atomicity |
| Data Integrity | Safe | Validation + backup recovery |
| Recovery | Safe | Automatic backup restoration |
| Conflict Resolution | Moderate | Domain-level merging (last write wins) |
Remaining Limitations
- Domain-level conflicts: If two processes update the same domain simultaneously, last write wins (but no data loss)
- Settings conflicts: Settings updates may overwrite concurrent changes
- Performance: File locking adds ~50-500ms overhead per write
- Lock cleanup: Stale locks handled with stale detection
Migration Path
The current implementation is production-ready for single-user scenarios. For multi-user or high-concurrency:
- Short-term: Current implementation is sufficient
- Medium-term: Add version numbers for better conflict detection
- Long-term: Migrate to SQLite for ACID guarantees