Issue with codegraph init failing to complete in my project. #1091

Activity

1. zmcrazy commented on Jul 1, 2026

   

   zmcrazy

   on Jul 1, 2026

   Author

   More actions

   I used the CODEGRAPH_NO_WATCHDOG=1 option, and it seems that indexing and everything else succeeded. However, when I actually use it, the following message appears:

   ⚙ codegraph_codegraph_explore [query=SIGSEC_DecodeBody]
   Thinking: CodeGraph is busy right now, so I need to use other tools. Let me try using the grep tool to find the definition and calls to the SIGSEC_DecodeBody function.
   ✱ Grep "SIGSEC_DecodeBody" (4 matches)
2. YoungLiao commented on Jul 1, 2026

   

   YoungLiao

   on Jul 1, 2026

   More actions

   meet the same problem on version
   1.1.5
3. GeeLab-Mob commented on Jul 1, 2026

   

   GeeLab-Mob

   on Jul 1, 2026

   More actions

   Same problem

   (base) ➜ xxxx git:(main) ✗ codegraph index
   ┌ Indexing project
   │
   │ ◆ Scanning files — 134 found
   │ ◆ Parsing code — done
   │ ✢ Resolving refs ██████████████████████░░░ 88%[CodeGraph] Main thread unresponsive for ~60s — killing the wedged process so a fresh one can start (#850). Disable with CODEGRAPH_NO_WATCHDOG=1.
   (base) ➜ xxxx git:(main) ✗ codegraph -v
   1.1.6
4. inth3shadows commented on Jul 1, 2026

   

   inth3shadows

   on Jul 1, 2026

   Contributor

   More actions

   Looks like slow-but-valid resolution being killed by the #850 watchdog rather than a size problem.

   If you're hitting this now (interim):

   • CODEGRAPH_NO_WATCHDOG=1 codegraph init disables the killer so the index can finish (as @zmcrazy found) — but it removes the safety net entirely.
   • Less blunt: keep the watchdog and widen its window, e.g. CODEGRAPH_WATCHDOG_TIMEOUT_MS=600000 (10 min). If resolution still never completes under a generous timeout, that would point to a genuine hang worth flagging rather than just slow work.
   • The "CodeGraph is busy" at query time (agent falling back to grep) looks like a separate problem from the index-time kill — probably worth its own issue.

   Root cause (for a fix):

   • Not scale — the 134-file repo reported above wedges the same way as the 22k-file one, so the trigger is in the resolution work, not file count.
   • Reference resolution runs synchronously on the indexer's main thread: resolveAndPersistBatched only yields (setImmediate) between 5000-ref batches — a single resolveAll(batch) doesn't yield, and the post-loop synthesizeCallbackEdges is synchronous too. The codegraph cause 100% CPU #850 heartbeat is a setInterval on that same thread, so once one of those spans exceeds the 60s window the child SIGKILLs the parent. The watchdog docstring's "won't fire on real work — indexing is off-thread" holds for parsing (parse-worker), but resolution isn't off-thread.
   • Maps to both traces here: …88% = a single large batch's resolveAll blocking; …100% then wedge = the post-loop callback synthesis running after the bar completes.

   (From code inspection on main, not a reproduction of the 60s hang — I don't have the reporters' trees, so the exact hot loop isn't pinned.)
5. colbymchenry

   added a commit that references this issue on Jul 1, 2026

   fix(index): yield during resolution so the liveness watchdog can't ki…

   ...

   ed39233
6. colbymchenry

   closed this as completedin #1105on Jul 1, 2026
7. colbymchenry commented on Jul 1, 2026

   

   colbymchenry

   on Jul 1, 2026

   Owner

   More actions

   Fixed in ed39233 (#1105) — this will ship in the next release.

   Root cause: the safety watchdog that kills a genuinely stuck index (#850) was mistaking slow-but-normal work for a hang. Reference resolution and cross-file relationship synthesis run on the same thread as the watchdog's heartbeat, and on a large project that work legitimately runs for a while without pausing — so the heartbeat couldn't fire and the watchdog killed a perfectly healthy, in-progress index. That's why it hit both the 22k-file and the 134-file projects: it was never really about file count, just a single stretch of synchronous work running past the 60s window.

   The fix makes that work yield periodically, so the heartbeat keeps firing during legitimate long indexing while a genuinely wedged process is still caught. You won't need CODEGRAPH_NO_WATCHDOG=1 anymore.

   Validated with the watchdog at its normal 60s setting on the Swift compiler source (~27k files, ~1.1M graph edges): the current release is killed by the watchdog partway through, while the fixed build indexes the whole thing to completion. Also verified on the TypeScript compiler, and node/edge output is byte-for-byte unchanged.

   Thanks @zmcrazy, @YoungLiao, and @GeeLab-Mob for the reports and the traces — they made this easy to pin down.

   👍React with 👍1Reacted by GeeLab-Mob
8. colbymchenry

   added a commit that references this issue on Jul 9, 2026

   fix(indexing): bounded-memory yielding pipeline tail + daemon session…

   ...

   a3f9008
9. fgabelmannjr

   added a commit that references this issue on Jul 9, 2026

   Merge upstream v1.3.1 into main (#33)

   ...

   e03aeed
10. colbymchenry

    added a commit that references this issue on Jul 10, 2026

    fix(sync): resolve cross-file refs when an edit adds or removes the s…

    ...

    9d0cd3a
11. colbymchenry

    added 2 commits that reference this issue on Nov 1, 2026

    perf(resolution): resolver workers take the main thread's C++ project…

    ...

    afa1e14

    fix(resolution): a large run waits for its pool, so the main thread d…

    ...

    4e96d75