fix(runner): track fs event watcher shutdown

[linkdata]

Summary

• track fsEventWatcher in the runner WaitGroup
• close the watcher before waiting so the goroutine exits cleanly
• keep the watcher pointer valid until after the goroutine has joined

Tests

• go test ./pkg/runner ./...

[coderabbitai]

Warning

Rate limit exceeded

@linkdata has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 59 minutes and 30 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 00bc8c6c-2422-441f-bbcb-20bf69c150c8

📥 Commits

Reviewing files that changed from the base of the PR and between b615285 and 87f60d8.

📒 Files selected for processing (1)

• pkg/runner/runner.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 59 minutes and 30 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[linkdata]

Additional context from comment files

These notes were split from the local markdown comment files and attached here because they describe this PR's change.

fsEventWatcher Goroutine Not Tracked

• Bug: The fsEventWatcher goroutine was started at line 1204 with go edm.fsEventWatcher() and was not tracked in any WaitGroup. When Run() exited, the goroutine was forced to terminate abruptly via fsWatcher.Close() on the deferred path, with no way to verify it had completed.
• Impact: Inconsistent shutdown semantics; potential for fsEventWatcher to be processing an event while the rest of the program shuts down; in the worst case, a callback could run while shared state was being torn down.
• Fix: (1) Added a *sync.WaitGroup parameter to fsEventWatcher with defer wg.Done(). (2) Tracked it in the main wg via wg.Add(1); go edm.fsEventWatcher(&wg). (3) Moved fsEventWatcher start to after wg is declared. (4) Added explicit fsWatcher.Close() before wg.Wait() so the goroutine has a signal to exit. (5) Made the deferred fsWatcher.Close into a safety net that checks for nil.
• Reasoning: All long-lived goroutines should be tracked by a WaitGroup for proper shutdown sequencing, matching the pattern used by other goroutines in the program.
• Tests: Verified by running the full test suite; no regressions.