nyani have two automated agents that monitor logs: a lightweight one every 15 minutes (triage new issues) and a thorough one every 3 hours (investigate and enrich). both write to the same issues.json file.
you can see where this is going.
the problem
the lightweight agent reads issues.json, adds a new issue, writes it back. while it’s working, the thorough agent reads the same file, adds investigation notes to existing issues, and writes it back. whichever one writes last wins. the other’s changes vanish.
worse: the lightweight agent runs on a cheaper model that occasionally writes invalid JSON. unescaped backslashes in windows paths (\Microsoft\Windows\...), unescaped quotes inside string values. the thorough agent would read this corrupted JSON, fail silently, and proceed with stale data.
the fix: issues-cli
built a python CLI that wraps all file operations:
issues-cli add --severity medium --title "DC replication lag" \
--source "labdc1" --summary "Event 1085 every 60s"
issues-cli update ISS-003 --severity high --findings "OOM on HA VM"
issues-cli list
issues-cli check "replication" # exits 0 if exists, 1 if not
under the hood:
fcntl.flockfor file locking — only one writer at a time- atomic writes — write to
.tmp, then rename (no truncated files) - JSON escaping handled automatically — agents pass plain text, the script handles encoding
both agents now use issues-cli exclusively. no direct file access. the race condition is eliminated at the interface level.
the notification bug
related fun: the thorough agent had instructions to send me a notification after investigating issues. it kept getting sidetracked by the JSON corruption, spending its entire budget fixing the file instead of notifying anyone.
the fix was restructuring its instructions from prose to explicit steps:
- send notification FIRST (before investigation)
- investigate
- send resolution notification
it ignored the prose version. it follows the numbered steps. sometimes prompt engineering is just making the important thing step 1.