Skip to content

codegraph deps / where --file report stale import edges even though the stored file_hashes entry matches current content #1731

Description

@carlos-alm

Summary

codegraph deps <f> / codegraph where --file <f> reported 5 import edges for src/presentation/audit.ts, but the file currently has only 3 imports. This is not an "unbuilt/stale graph, needs rebuild" situation in the usual sense — the file_hashes table's stored hash for this file exactly matches the current on-disk content's sha256, yet the edges table still holds 2 additional imports rows that don't exist in the current source. So the incremental build is treating the file as unchanged (correctly, by hash) while simultaneously holding edge data from a prior version of the file — i.e. hash-based change-detection and edge data are out of sync with each other for this node.

Repro (this worktree, .codegraph/graph.db)

$ grep -n "^import" src/presentation/audit.ts
1:import { kindIcon } from '../domain/queries.js';
2:import { auditData } from '../features/audit.js';
3:import { outputResult } from '../infrastructure/result-formatter.js';

$ shasum -a 256 src/presentation/audit.ts
10dd48dbd0bb9706e576f0b806ee17f03f8d50a0587115a99f1693887bfc8e42  src/presentation/audit.ts

$ sqlite3 .codegraph/graph.db "SELECT * FROM file_hashes WHERE file='src/presentation/audit.ts';"
src/presentation/audit.ts|10dd48dbd0bb9706e576f0b806ee17f03f8d50a0587115a99f1693887bfc8e42|1782970911441|3572

$ sqlite3 -header -column .codegraph/graph.db "
SELECT e.id, n1.file as src_file, n2.file as target_file, e.kind
FROM edges e JOIN nodes n1 ON e.source_id=n1.id JOIN nodes n2 ON e.target_id=n2.id
WHERE n1.file='src/presentation/audit.ts' AND e.kind='imports';"
id     src_file                   target_file                             kind
62952  src/presentation/audit.ts  src/domain/queries.ts                   imports
62953  src/presentation/audit.ts  src/shared/normalize.ts                 imports
62954  src/presentation/audit.ts  src/features/audit.ts                   imports
62955  src/presentation/audit.ts  src/infrastructure/result-formatter.ts  imports
62956  src/presentation/audit.ts  src/presentation/result-formatter.ts    imports

The stored file_hashes sha256 for the file is byte-identical to the current file's sha256 — so this isn't the ordinary "edit a file, forget to rebuild" case where a mismatched hash would correctly trigger a re-parse. Something updated (or left) the hash correctly while the edge rows from an older version of the file (which apparently imported shared/normalize.ts and presentation/result-formatter.ts too) were never purged/regenerated.

Impact

codegraph deps/codegraph where --file cannot be trusted for dependency-direction / architecture-boundary auditing even against a graph whose file_hashes claims to be current — the standard "is the graph stale, do I need to rebuild" check (compare stored hash to file content) is not sufficient to guarantee edge correctness for every node.

Expected

If a file's edges are ever regenerated, they should always correspond to the same content revision reflected in file_hashes for that file — either both are updated together, or neither is until a full re-parse of that file completes.

Context

Found while running the Titan GAUNTLET quality-audit pass (/titan-gauntlet) over src/presentation/audit.ts, in a worktree at HEAD 597ed1c3036ebb2c5f6fe457be9d156bdf33d273 (codegraph v3.15.0). Have not root-caused which prior operation (incremental build path, snapshot restore, etc.) left the edges stale; flagging with a concrete, reproducible repro for the maintainers to trace further.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions