There appears to be a race condition between the file watcher and harvester goroutines, when the file is modified right around the time the close.on_state_change.inactive timer expires:

File watcher goroutine:

• filestream receives a "write" event and updates internal state (fswatch.go).
• A harvester is already running at this stage, so it exits with a "harvester already running" error.

Harvester goroutine:

• filestream detects that the file has been idle for 5 minutes.
• It cancels the context before it could detect the new changes.

This leads to a situation where a write occurs, but the harvester exits too early due to the inactive timeout, and a new harvester isn't started because the watcher has already updates its state. As a result, new data may be missed.