`source_file` reduced to bare basename for all nodes in 0.9.16 (was relative path in 0.9.13) — breaks resolution against a code root

[JensD-git]

Summary

Between graphifyy 0.9.13 and 0.9.16, the source_file field on nodes changed from a path relative to the scan root to a bare filename (basename only) — for every node, not just the cases mentioned in the release notes. This removes the only field that carried the file's directory, so a graph.json can no longer be resolved back to files on disk by joining source_file onto the scan/code root.

I'm not sure whether this is intended. The 0.9.14/0.9.16 notes describe making paths portable/relative for narrow cases (VS solution-folder nodes → "now relative"; out-of-root reference targets and degenerate symbols → "now portable"), but a relative path is already free of absolute-path/username leaks, so the wholesale reduction to basename seems to go beyond what's documented. Hence this report/question.

Environment

• graphifyy 0.9.13 (baseline) vs 0.9.16 (observed change)
• Windows 11, Python 3.14
• Language: C# (nodes are _origin: ast, so this is AST-derived and independent of the semantic backend)

Steps to reproduce

1. Extract any C# tree that has files in nested subdirectories:
   graphify extract <ROOT> --out <OUT>
2. Inspect source_file on the nodes in the resulting graph.json.
3. Compare the same extraction under 0.9.13 and 0.9.16.

Expected

source_file is a path relative to the scan root (as in 0.9.13), e.g. keeping the subdirectory so the file is locatable via <root>/<source_file>.

Actual

source_file is the bare filename only; the directory component is gone.

Same file, both versions (example):

version	source_file
0.9.13	src/Data/Database/RepositoryTests/OrderRepositoryTests.cs
0.9.16	OrderRepositoryTests.cs

Aggregate over one representative graph (~120k source_file occurrences):

version	with a path separator (/)	basename only
0.9.13	117,897	7,335
0.9.16	0	119,341

No other field carries the path in 0.9.16. Node keys are [id, label, source_file, source_location, file_type, community, norm_label, type, metadata]; source_location is a line only (e.g. "L14"), and a scan of every string value on every node finds 0 nodes containing a directory separator in any .cs-bearing value.

The full directory does survive, but only slugified and lossy, inside the type node id, e.g.:

id = c_..._src_data_database_repositorytests_orderrepositorytests_...

i.e. lowercased with ., /, \, -, spaces all collapsed to _ (and truncated). Because those distinct characters all map to _, this can't be reversed to a filesystem path reliably.

Impact

Any downstream tooling that resolves nodes back to source by joining source_file onto the scan/code root breaks: 0% of files resolve after the change. The lossy id slug is not a viable substitute.

Questions

1. Is the basename-only source_file for in-root files intended, or an over-broad side effect of the out-of-root / degenerate-symbol leak fixes?
2. If intended: is there (or could there be) a field carrying the portable relative path (as the 0.9.14 "now relative" direction suggests), so a graph.json remains resolvable against its root without parsing the id slug?

[SinghAman21]

A1: Not intended — it's a bug. The basename fallback (#1899, b3dc15b) was meant only for out-of-root reference targets. But --out rebinds the relativization anchor to the out dir (cli.py:2274 → extract.py:4340), so with --out every file counts as "out-of-root" and collapses to a basename — on Windows with the out dir on another drive, unconditionally. That's their 119,341/0.

A2: No such field exists. graph.json carries no file table or scan root; origin_file is stripped (#1516). Once basenamed, the directory is gone — the id slug is lossy, as they said. But it should be fixed by anchoring on the scan root, not by adding a new field.