* fix(watcher): follow a rebuilt index instead of syncing into the replaced file (#1902)
`codegraph index` rebuilds through `CodeGraph.recreate()`, which unlinks
`.codegraph/codegraph.db` and creates a new file at the same path. A running
MCP daemon kept its handle on the unlinked inode and its watcher kept
"auto-syncing" into it, so no edit reached the on-disk index. The #925
self-heal only ran on the tool-call path and ran no catch-up after reopening.
- `sync()` now checks, once it holds the index mutex and the write lock,
whether the database was replaced on disk (one stat, the same inode check
`reopenIfReplaced` uses). If so it reopens the live file in place and widens
a scoped sync to a full reconcile. A failed reopen (rebuild mid-way) returns
the lock-busy shape so the watcher keeps its pending files and retries.
- `reopenIfReplaced()` refuses while an index/sync holds the mutex, so the
tool-call path never closes the handle an in-flight sync writes through.
- When a tool call's `freshen()` does reopen, the engine runs its existing
catch-up sync (serialized on the same mutex), but only for its own watched
instance, so an engine that is not the project's writer never writes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(sync): step aside for a rebuild that has recreated the file but not locked it yet
`codegraph index` recreates the database, then takes the write lock inside
indexAll. With the watcher now following a replaced file, a sync landing in
that gap reopened the empty file and started a full reconcile, holding the
lock the rebuild was about to request — `codegraph index` could then fail
with "another process may be indexing". Review flagged the gap; this closes
it. After following a replaced file, a sync that finds no index_state yet
(the rebuild has not started indexing) and a file written within the last
two minutes returns the lock-busy shape so the watcher retries; the first
sync after that reconciles the whole tree once, then syncs go back to scoped.
The time bound keeps a rebuild that died before indexing from parking the
watcher forever.
New test: fails without the guard, passes with it; 136 related tests pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(sync): keep the full catch-up until a full sync completes (#1902)
Two gaps in following a replaced database:
- Only a reopen done by sync() itself set pendingFullReconcile. The tool-call
self-heal (reopenIfReplaced) swapped the handle without it, so the next
scoped watcher sync skipped whatever the old handle had absorbed. The flag
is now set wherever the database is reopened.
- The flag was cleared before the sync ran, so a sync that threw lost the
catch-up. It is now cleared only after a full sync completes.
Ported from the maintainer's hardening of this fix in #1919.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(sync): report a rebuild in progress as lock contention, not an empty sync (#1902)
Since #2014 the watcher tells lock contention apart from success only by
LockUnavailableError; it no longer recognises the all-zero result. Following
a rebuilt index still returned that shape when the reopen failed or when the
recreated file had not been indexed yet, so the watcher counted the step-aside
as a clean sync and dropped the pending edits. Both paths now throw
LockUnavailableError. A watcher test proves the edit stays pending through the
rebuild gap and is reconciled once the rebuild finishes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: danusha2345 <danusha2345@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: danusha2345 <ewidusoc498@gmail.com>
Daniil
e5a3d85b0c