v1.1.4: existing oversized index from ignored gitlinks cannot be rebuilt; index watchdog still kills command

[AriaShishegaran]

Summary

After upgrading to CodeGraph v1.1.4, the scanner fix from #1065 appears to work for a fresh index, but an existing oversized .codegraph state produced by earlier versions still cannot recover via codegraph index.

In the affected repo, codegraph index --verbose prints only:

┌  Indexing project

Then, after about 60 seconds:

[CodeGraph] Main thread unresponsive for ~60s — killing the wedged process so a fresh one can start (#850). Disable with CODEGRAPH_NO_WATCHDOG=1.

Exit code is 137.

This is specifically problematic in the Doctorine repo because previous CodeGraph versions indexed a gitignored benchmark corpus of embedded repos. Other/fresh checkouts now succeed on v1.1.4.

Environment

• CodeGraph: 1.1.4
• OS: macOS / Darwin arm64
• Repo shape: private TypeScript monorepo with a local benchmark/reference corpus of public cloned repositories under benchmark/repos/
• benchmark/repos/ entries are tracked gitlinks (160000) and also physically exist as nested git repos on disk
• No private source content is included in this report

Relevant ignore/gitlink shape

Root .gitignore contains:

benchmark/corpus/
benchmark/repos/
benchmark/**/node_modules/

Gitlink count:

git ls-files -s benchmark/repos | awk '$1 == 160000 {c++} END {print c+0}'
# 19

Git agrees the path is ignored when checking as an ignored working-tree path:

git check-ignore --no-index -v benchmark/repos benchmark/repos/fern benchmark/repos/RapiDoc benchmark/repos/swagger-ui
.gitignore:82:benchmark/repos/ benchmark/repos
.gitignore:82:benchmark/repos/ benchmark/repos/fern
.gitignore:82:benchmark/repos/ benchmark/repos/RapiDoc
.gitignore:82:benchmark/repos/ benchmark/repos/swagger-ui

What is fixed in v1.1.4

Calling the installed v1.1.4 scanner APIs directly from the affected working tree now looks correct:

{
  "scanDirectory": {
    "count": 2256,
    "benchmarkRepos": 0,
    "benchmark": 5,
    "sampleBenchmarkRepos": []
  },
  "discoverEmbeddedRepoRoots": {
    "count": 0,
    "benchmarkRepos": 0,
    "sample": []
  },
  "buildScopeIgnore": {
    "benchmarkReposDir": true,
    "benchmarkReposChildDir": true,
    "benchmarkReposFile": true
  }
}

A fresh v1.1.4 init on a temp copy of the same working tree, with the ignored benchmark repos physically present but no old .codegraph, also succeeds:

◆  Indexed 2,256 files
●  25,338 nodes, 87,893 edges in 7.6s
└  Done

Running codegraph index --verbose again in that fresh temp copy also succeeds:

◆  Indexed 2,256 files
●  25,338 nodes, 87,893 edges in 9.0s
└  Done

So the v1.1.4 scanner fix is working for fresh state.

What is still broken

The original repo still has the old oversized graph from the pre-fix scan:

codegraph status
Files:   140,701
Nodes:   1,595,121
Edges:   1,776,928
DB Size: 4929.61 MB
Backend: node:sqlite — built-in (full WAL)
Journal: wal

SQLite file sizes in .codegraph/:

codegraph.db      4.8G
codegraph.db-wal  4.0G
codegraph.db-shm  7.9M

The indexed file distribution confirms the old bad graph is dominated by the ignored corpus:

benchmark       138,450 files, 483.9 MiB source bytes
packages          1,053 files,   4.3 MiB
apps                824 files,   3.9 MiB
services            211 files,   1.1 MiB

More specifically:

files where path like 'benchmark/repos/%' = 138,445

Top embedded repo contribution:

benchmark/repos/fern        125,741 files
benchmark/repos/scalar        5,321 files
benchmark/repos/redocly-cli    1,665 files
benchmark/repos/docusaurus     1,277 files
benchmark/repos/zudoku           830 files
benchmark/repos/swagger-ui       822 files

The old graph metadata says it was built with an older version:

indexed_with_version|1.1.1
indexed_with_extraction_version|24

On this state, codegraph index --verbose on v1.1.4 never reaches the visible Phase: scanning output. It just prints Indexing project and then the watchdog kills it after about 60 seconds.

I also stopped stale codegraph.js serve --mcp daemons from older versions and retried. The result was unchanged:

┌  Indexing project
[CodeGraph] Main thread unresponsive for ~60s — killing the wedged process so a fresh one can start (#850). Disable with CODEGRAPH_NO_WATCHDOG=1.

Expected behavior

Because codegraph index is documented as rebuilding the full index from scratch, it should recover from an old bad index state after upgrading to v1.1.4.

Reasonable expected outcomes would be either:

1. codegraph index safely discards/replaces the old oversized DB and produces the fresh 2,256 file graph, or
2. it detects that the existing DB/WAL is too large or stale and prints a clear instruction such as removing/reinitializing .codegraph, rather than wedging until the watchdog kills it.

Actual behavior

Fresh v1.1.4 state works. Existing oversized state from the pre-fix gitlink scan does not recover with codegraph index; it still hangs/crashes in this repo.

Why this is a separate follow-up from #1065

#1065's scanner/root-cause fix appears successful in v1.1.4 for fresh state. This issue is about the recovery path for users who already have a large poisoned .codegraph DB/WAL from v1.1.1/v1.1.3 era indexing. The advertised command says it rebuilds from scratch, but in practice the old DB state can still wedge the command before scanning starts.

[colbymchenry]

Fixed in #1073 (merged to main, ships in the next release). Thanks for the precise follow-up — separating "fresh state works" from "the old poisoned DB still wedges" is exactly what made this quick to pin down.

What was happening: you correctly identified this as separate from #1065. The scanner fix there stopped new indexes from pulling in the ignored gitlink corpus, but codegraph index cleared the old graph by issuing DELETE FROM across the tables. The nodes table has a full-text-search index with an AFTER DELETE trigger, so deleting ~1.6M rows fires ~1.6M FTS delete-markers — and that work grows the WAL further before it can finish. On your graph that ran well past the 60s main-thread watchdog, so the process was killed (exit 137) before scanning ever started. open() was never the wedge, which matches what you saw (Indexing project printed, then nothing).

The fix: codegraph index is documented as "same result as a fresh init", so it now is one — it discards the database files (codegraph.db + -wal/-shm) and re-initializes from scratch instead of deleting rows one-by-one. Unlinking is constant-time regardless of the old size, so it can't trip the watchdog, and it also reclaims the disk the bloated DB/WAL were holding. Validated end-to-end on macOS, Linux, and Windows, including recovering a real ~800K-node / 419 MB poisoned database in ~0.3s.

To recover right now on v1.1.4 (before the next release): a fresh init already works for you, so rm -rf .codegraph && codegraph init will rebuild the correct small graph. Once you upgrade to the release with this fix, plain codegraph index will handle it on its own.