[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 a gap in the file-data Watcher when a configured symlink could not be resolved and later points at a file in a directory that was already watched (for example because another configured path lives there). refresh_links now treats newly resolved link targets as a change even when no new inotify watch is added, so the once-per-second retry still invokes on_change once and stale file data is not left unread.

Watcher documentation no longer implies that every repointed symlink is followed. It now calls out layouts the watcher does not detect—mid-chain repoints while the old target remains, a configured directory that is itself a symlink and is switched, or rename-and-replace of a configured directory—and recommends polling for patterns like a current release symlink.

Adds a spec that creates the missing intermediate directory as a link into an already-watched folder and expects the callback after resolution.

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

[kinyoklion]

bugbot review

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

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

[cursor]

Failed watch retriggers callback every retry

Low Severity

When a resolvable link's directory is missing from @watched, the new target check treats every name as unseen. If add_watch then fails, that directory is never recorded, so each retry reports a change and retry_start fires the callback again.

Additional Locations (1)

• lib/ldclient-rb/impl/file_data/watcher.rb#L315-L321

 

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