[kinyoklion]

Summary

Follow-up to #449 for two findings raised on the Python port of the same watcher (launchdarkly/python-server-sdk#525), both of which apply here.

• A configured link that cannot be resolved keeps the once-per-second retry running. When a retry resolved such a link to a target in a directory that was already watched, for example because another configured file is in it, it added no watch and so ran no callback. Content that appeared while the link could not be resolved was then not read until some later change. refresh_links now reports a change whenever a link leads to a target it did not lead to before, so the retry runs the callback once.
• The watcher comment said that a link that comes to point elsewhere is followed. That holds when the old target's directory is deleted, as a ConfigMap update does, but not for a link further along the chain that is pointed elsewhere while its old target stays, a configured directory that is itself a link and is pointed elsewhere, or a configured directory that is renamed and replaced. The comment now names those cases and points such deployments, like a current link to a release directory, to polling, which is the default. The override source's change_detection documentation says the same in feat: Add the file-based override source #453.

Tests

A new watcher spec configures a link that leads through a directory that does not exist yet to a directory that another configured file keeps watched, then creates the missing directory as a link. It fails without the change and passes with it. The watcher specs pass (24 examples), the full suite passes apart from spec/launchdarkly-server-sdk_spec.rb:5, which fails the same way on feat/overrides on this box because Bundler cannot write its lock file, and RuboCop reports no offenses.

SDK-3249

_{Opened from termag}

---

Note

Overview
Fixes file data watcher behavior when a configured symlink finally resolves to a file in a directory that was already being watched (e.g. another configured path). refresh_links now treats newly discovered link targets in existing watches as a change, so the retry loop invokes on_change once instead of silently skipping until some unrelated filesystem event.

Watcher docs are tightened to list symlink/deployment patterns inotify does not track (mid-chain repointing, directory-as-symlink swaps, rename-and-replace layouts) and to steer current → release style setups toward polling.

Specs cover resolution into an already-watched directory and assert the callback is not fired on every failed watch retry.

^{Reviewed by Cursor Bugbot for commit d232195. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kinyoklion]

bugbot review

[cursor]

Stale Bugbot comment from a previous run.

[kinyoklion]

bugbot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d232195. Configure here.}