Droid incremental reader test flakes: same-size edit within one mtime tick is not detected

Open
#2,813 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
50/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, node.js
Domain
backend, testing

Research direction

Start with test/plugins/droid.test.js:66 and the failure at line 88, then read hypaware-core/plugins-workspace/droid/src/transcript.js:74-77 to trace how the cursor fingerprint and boundary determine whether to resume reading. Decide whether the test should force a distinct mtime or the reader should handle same-size edits within one timestamp tick. Done means the flaky case is addressed and the test reliably verifies the intended behavior.

Written by the indexing model from the issue text.

Description

test/plugins/droid.test.js:66 ("Droid incremental reader handles append, partial UTF-8 lines, header rewrites and same-size edits") fails intermittently on master code. Seen in a full npm test run on a branch whose only change is package.json (#2812), then 1 failure in 5 runs of the file alone on Linux.

Failure, at line 88:

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
0 !== 5

Likely cause: readDroidTranscript (hypaware-core/plugins-workspace/droid/src/transcript.js:74-77) treats a cursor as still valid at the same file size when cursor.fingerprint === currentFingerprint and the 128 bytes before the offset are unchanged. The fingerprint is dev:ino:size:mtimeMs:ctimeMs. The test rewrites the file twice in quick succession with the same size, and the second edit is to record 1, well before the last 128 bytes. When both writes land in the same kernel timestamp tick (coarse, a few ms on Linux), the fingerprint and boundary are identical, so the reader resumes at the old offset and yields 0 rows.

So this is a test flake and also a small product edge: a same-size edit within one timestamp tick of the previous write is not replayed. The test could wait for a distinct mtime (or set one with fs.utimes) before the same-size edit; whether the reader should also cover the sub-tick case is a separate call.

🤖 Generated with Claude Code

Dominant language
JavaScript
Stars
11
Forks
0
Avg merge
2h 55m
Merged PRs (30d)
294

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hyparam/hypaware

All issues in hyparam/hypaware

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.