Issue with codegraph init failing to complete in my project.

[zmcrazy]

Hi, I attempted to execute codegraph init -i in my source code project, but the operation failed. Is it because the project is too large? Do I set CODEGRAPH_NO_WATCHDOG=1 to OK?

codegraph init -i
┌ Initializing CodeGraph
│
◆ Initialized in D:\open_src\GW
|
| * Scanning files - 22,758 found
| * Parsing code - done
| * Resolving refs ######################### 100%[CodeGraph] Main thread unresponsive for ~60s 鈥?killing the wedged process so a fresh one can start (#850). Disable with CODEGRAPH_NO_WATCHDOG=1.

[zmcrazy]

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)

[YoungLiao]

meet the same problem on version
1.1.5

[GeeLab-Mob]

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

[inth3shadows]

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.)

[colbymchenry]

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.