Summary
When reference resolution is interrupted mid-sync (process kill, crash — e.g. the pre-fix #1558 stack overflow), the next sync's orphaned-ref sweep does resume the pending refs — but it resolves them measurably worse than the normal batched path, and does so behind an "Already up to date" banner (#1360). The result is a permanently degraded edge set that no further sync repairs, because the under-resolved refs are parked failed.
Measured (cpython Lib/, 1,753 files, current main)
Setup: a sync re-indexing 939 files stored all nodes, then resolution died mid-way (the #1558 crash, since fixed), leaving 234,440 refs pending. A second plain codegraph sync:
Node counts and per-file symbol counts were identical to the clean run throughout — only the sweep-resolved edge set diverges, which makes it invisible to everything except a graph dump diff (scripts/dump-graph.mjs).
A third sync changes nothing: the refs are failed, and with no changed files there is no definition delta to retry them against.
Likely direction
The sweep hands the orphaned refs to resolution without whatever ordering/context the batched path guarantees (e.g. import refs resolving before the call refs that depend on them — the "insert edges before fan-out" invariant the batched loop maintains). Since the interrupted files' import edges may themselves be missing at sweep time, viaImport resolution fails and the refs park as failed even though their targets exist.
Repro
Kill a sync during its resolution phase (SIGKILL once parsing hits 100%), then run codegraph sync twice and dump-diff against a clean init of the same tree. (Before the #1558 fix, any dense recovery sync produced this state on its own.)
Related: #1360 (the misleading banner), #1187/#1191 (interrupted-resolution orphan lineage), #1558 (the crash that exposed it).
Summary
When reference resolution is interrupted mid-sync (process kill, crash — e.g. the pre-fix #1558 stack overflow), the next sync's orphaned-ref sweep does resume the pending refs — but it resolves them measurably worse than the normal batched path, and does so behind an "Already up to date" banner (#1360). The result is a permanently degraded edge set that no further sync repairs, because the under-resolved refs are parked
failed.Measured (cpython
Lib/, 1,753 files, current main)Setup: a sync re-indexing 939 files stored all nodes, then resolution died mid-way (the #1558 crash, since fixed), leaving 234,440 refs
pending. A second plaincodegraph sync:Already up to datewhile it resolved all 234,440 pending refs (the sync prints "Already up to date" while it is actually resolving thousands of orphaned refs (misleading output) #1360 shape, with data);failedvs 122,020 in the clean run — ~61,665 refs that resolve fine in the batched path failed in the sweep.Node counts and per-file symbol counts were identical to the clean run throughout — only the sweep-resolved edge set diverges, which makes it invisible to everything except a graph dump diff (
scripts/dump-graph.mjs).A third sync changes nothing: the refs are
failed, and with no changed files there is no definition delta to retry them against.Likely direction
The sweep hands the orphaned refs to resolution without whatever ordering/context the batched path guarantees (e.g. import refs resolving before the call refs that depend on them — the "insert edges before fan-out" invariant the batched loop maintains). Since the interrupted files' import edges may themselves be missing at sweep time,
viaImportresolution fails and the refs park asfailedeven though their targets exist.Repro
Kill a sync during its resolution phase (SIGKILL once parsing hits 100%), then run
codegraph synctwice and dump-diff against a clean init of the same tree. (Before the #1558 fix, any dense recovery sync produced this state on its own.)Related: #1360 (the misleading banner), #1187/#1191 (interrupted-resolution orphan lineage), #1558 (the crash that exposed it).