Skip to content

fix: Retry after partial file reads.#218

Draft
kinyoklion wants to merge 40 commits into
mainfrom
rlamb/file-data-source-json-retry
Draft

fix: Retry after partial file reads.#218
kinyoklion wants to merge 40 commits into
mainfrom
rlamb/file-data-source-json-retry

Conversation

@kinyoklion
Copy link
Copy Markdown
Member

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.

@kinyoklion kinyoklion force-pushed the rlamb/file-data-source-json-retry branch from f3aaa08 to d1f90f1 Compare January 9, 2026 23:00
The two reload tests asserted an exact ExpectedDataSetForSegmentOnlyFile(2),
which encoded an assumption of exactly two LoadAll attempts. With the file
watcher firing on truncate-then-write plus the new JSON-parse retry, the
successful attempt's version can be 3+ and the strict JSON comparison times
out waiting for a version-2 event that never comes.

Switch both tests to ExpectPredicate with a shared structural matcher and
refactor the existing predicate in ModifiedFileIsReloadedIfAutoUpdateIsOn
to use the same helper.

Also tighten the retry path in FileDataSource: drop the trailing TODO,
short-circuit LoadAll once Dispose() has been called, and skip the post-
delay LoadAll if disposal raced the retry.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant