fix: Retry after partial file reads.

[kinyoklion]

When we detect a file has been written there isn't any promise that the file content itself will actually be complete, or that a subsequent notification for that file will be received when it is.

Currently sometimes the file update will trigger, and the JSON parsing will fail, and then it won't get re-triggered. Which causes some tests to fail.

This introduces a retry for any failed JSON parsing up to a maximum number of times.

Ideally we would extract the file watcher and abstract the file system API so we could simulate these conditions.

---

Note

Overview
When auto-update is enabled, FileDataSource now retries loads after parse failures (e.g. reading a file mid-write), up to 5 attempts with a 600 ms delay between tries, instead of stopping until another file-change event.

Retries are scoped to per-episode failure budgets: a new Start() or watcher reload clears counts and starts fresh. Auto-update off keeps the documented one-shot load—no background retries. Multi-path loads share a single retry chain; if one path exhausts its budget, other paths that were waiting on retries get terminal error logs and wait for the next change.

Dispose cancels pending retries; a successful external reload before a scheduled retry avoids redundant Init and spurious change events. Transient read errors during a retry episode are charged to the same per-path budget as parse failures.

Builder docs for AutoUpdate describe the bounded retry behavior. Tests use scripted file readers and relaxed reload assertions where watcher timing makes versions non-deterministic.

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

[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 64cb514. Configure here.}

[cursor]

Error logged before retriable failure

Low Severity

LogHelpers.LogException always runs before HandleRetryLoadFailure, so every retriable read failure during a retry episode is logged at Error even though a Warn retry follows. That diverges from HandleParseFailure, which keeps retriable failures at Warn and reserves Error for giving up, and can falsely look like a terminal load failure to operators and monitors.

Additional Locations (1)

• pkgs/sdk/server/src/Internal/DataSources/FileDataSource.cs#L210-L229

 

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