Skip to content

fix(daemon): use sub-second mtime precision in run index cache#390

Open
proboscis wants to merge 1 commit intomainfrom
issue/orch-400/run-20260201-104756
Open

fix(daemon): use sub-second mtime precision in run index cache#390
proboscis wants to merge 1 commit intomainfrom
issue/orch-400/run-20260201-104756

Conversation

@proboscis
Copy link
Owner

Summary

  • Fix run status showing boot or fail when runs are actually running
  • Root cause: run index cache used second-granularity mtime comparison (.Unix())
  • When status events were appended within the same second, the cache returned stale data

Problem

The run index cache at internal/store/file/run_index.go compared file modification times using .Unix(), which truncates to second precision. When the daemon appended a status event (e.g., running) and then immediately re-read the run list, the mtime comparison would pass (same second) and the stale cached status (e.g., booting) would be returned.

This caused:

  • Runs showing boot status when they were actually running
  • Runs showing fail status after dead checks when the running status was already written

Fix

Changed mtime comparison from .Unix() to .UnixNano() for nanosecond-precision comparison, ensuring the cache is properly invalidated when files are modified within the same second.

Testing

  • All existing tests pass (go test ./internal/store/file/..., go test ./internal/daemon/..., go test ./internal/agent/...)
  • Build succeeds (go build ./...)

Fixes

  • orch-400

The run index cache used Unix() for mtime comparison, which only has
second-level precision. When status events were appended within the
same second, the cache would return stale data because the mtime change
was not detected.

This caused runs to show incorrect status (boot/fail) when they were
actually running, because the daemon saw stale cached status instead
of the updated status from disk.

Changed to UnixNano() for nanosecond-precision mtime comparison,
ensuring cache invalidation when files are modified.

Fixes: orch-400
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant