[Bug]: WatchStore recovery overwrites its readable backup

Open
#7,496 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@123XieC is already working on this.

Since Nov 12, 2026.

  • #7497 by @123XieC — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
python
Domain
backend, database

Research direction

Start by locating FileWatchStore.initialize() and its snapshot save and recovery paths; the issue does not name file paths or tests. Trace how the readable backup is used and how the primary is rewritten, then look for tests covering invalid primary JSON and a failed final move. Done means a retry can still recover the watch from the backup after that move fails.

Written by the indexing model from the issue text.

Description

Issue Origin

Observed or reproduced in a real environment. The reproduction uses the real local RAGFS backend and on-disk snapshots.

Bug Description

When the primary watch-task snapshot is invalid JSON and the backup is readable, FileWatchStore.initialize() recovers the task rows from the backup. While rewriting the primary, the normal save path rotates the invalid primary over the only readable backup. If installing the recovered primary fails after that rotation, no readable snapshot remains.

Steps to Reproduce
  1. Use a local FileWatchStore and create a watch. Update it once to generate a valid backup.
  2. Write invalid JSON to .watch_tasks.json.
  3. Reopen the store. Inspect the backup after initialization. To exercise a failed restore, reject only the move from the temporary snapshot to the primary and then retry initialization.
Expected Behavior

Restore the primary from the readable backup without rotating the corrupt primary over it. If the final move fails, a retry should still be able to load the watch from the same backup.

Actual Behavior

The backup contains the corrupt primary bytes after both a successful restore and a simulated failure of the final move.

OpenViking Version

Current main at 5043e1f, with the local RAGFS Python binding from the OpenViking 0.5.3 macOS wheel.

Python Version

Python 3.12.

Operating System

macOS arm64.

Additional Context

#7133 and #7086 cover startup when snapshots cannot be read. This reproduction starts from a readable backup and fails during the recovery write. It was investigated and reproduced with AI assistance.

Dominant language
Python
Stars
41.8k
Forks
3.4k
Avg merge
19h 29m
Merged PRs (30d)
500

Getting set up

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 volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.