Fixed 🔒
Fixed fallback logic in content lock
v1.6.2 had a bug: when the lock was held by another process (not an error), the code still proceeded without the lock via the fallback branch. This could still cause duplicate notifications.
What changed
- Now correctly exits when another process holds the lock
- Only uses fallback on actual errors (e.g., /tmp unavailable)
- Simplified code by removing redundant else branch
- Uses
deferfor cleaner lock release
How it works now
Process A: acquires lock → checks duplicate → saves state → sends notification → releases lock
Process B: tries to acquire lock → lock busy → exits immediately (no notification)
Full Changelog: v1.6.2...v1.6.3