Hourly event-loop stalls: bursts of directory events trigger overlapping synchronous resyncs, /health unresponsive up to ~90s

[thenotoriousllama]

Observed (2026-07-03 production soak, Windows)

A health watchdog polling /health every 60s recorded, over ~7 hours of an otherwise healthy soak:

• 14:51 local: poll timeout (15s); daemon log shows 8 directory events between 14:51:19 and 14:51:44 each logging "directory event: requesting resync" (test/telemetry, src, scripts, and five library/knowledge dirs)
• 16:22: /health response took 12.9s
• 17:52: response took 20.2s
• 19:52: response took 13.1s
• 21:23 and 21:24: two consecutive poll timeouts (25s each); healthy again by 21:25

Pattern is roughly hourly, consistent with an external scanner (search indexer, AV, backup) touching directories and emitting directory-level watch events.

Root cause chain

1. An external hourly scan generates directory-change events across many directories at once.
2. Each directory event triggers a resync request (the PRD-018c directory-event rule).
3. The resync's work is synchronous on the event loop: git ls-files spawn for the shared ignore predicate refresh, statSync walk over the tree, and hashing where needed.
4. Multiple back-to-back resyncs monopolize the event loop; the HTTP server cannot answer /health for 13-90s.

Why it matters

Self-recovering on a dev box, but under fleet supervision a doctor probing /health with a 10-15s timeout would classify the daemon unhealthy during every stall window and could start restart remediation against a healthy process (compounding with the single-instance lock).

Fix directions

• Coalesce resync requests: at most one queued resync; a burst of N directory events becomes one pass (cheap, biggest win).
• Let the resync breathe: yield to the event loop between per-file steps (setImmediate batching) or move the walk/hash work off-thread.
• Consider filtering directory events whose children show no content change before requesting a full resync.

Evidence

Watchdog log excerpts and the daemon log burst are preserved in the 2026-07-03 soak session; the resync trigger timestamps above are from the daemon's registration.cycle log lines.

[coderabbitai]

🔗 Related PRs

#11 - Implement PRD-017: service check-in and SQLite telemetry [merged]
#18 - PRD-018: pre-release close-out - fix all 42 NEC issues across the three mission legs [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[thenotoriousllama]

Overnight soak data (19h uptime) confirms the hourly pattern: SLOW 18.2s response at 04:52, poll timeouts at 07:53 and 08:53, all at the ~:52 mark. Separately the bridge's cumulative flushFailures counter moved 2 -> 4 at 09:21 local, consistent with durable flushes landing inside a stall/blip window; resync self-heal reconverges state. Coalescing resync requests remains the recommended first fix.