C/C++ #include not mapped as IMPORTS edges — expected or a bug?

[Zeermil]

Version

codebase-memory-mcp 0.9.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

I indexed a mixed C++/Kotlin/Python project using codebase-memory-mcp v0.9.0 on Windows.

Kotlin/Python files get IMPORTS edges correctly
C++ files — none of the #include directives produce IMPORTS edges in the graph
Example: main.cpp #includes NodeController.h, but the graph only shows IMPORTS from main.cpp to NodeController.cpp (Module node), not to the header file. Most C++ .cpp and .h files end up with zero incoming edges.

Query:

MATCH (f:File) WHERE NOT EXISTS { (f)<-[:IMPORTS|CALLS|CONTAINS_FILE|DEFINES|USAGE]-() } RETURN count(f)
Returns 194 out of 214 total files, even though most of those are actively used via #include in the build system.

My setup:

Platform: Windows (amd64)
Binary: codebase-memory-mcp v0.9.0 (windows-amd64, static binary)
Project type: PlatformIO (C++/Arduino) + Android (Kotlin) + Python backend
Index mode: full, CBM_WORKERS=1 (no crashes, status: "indexed")

Is missing C/C++ #include → IMPORTS mapping a known limitation?
Are C/C++ #include dependencies tracked under a different edge type that I'm missing?
Is there a workaround or pending fix for this?
Thanks!

Reproduction

none

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

4028 nodes / 15847 edges / 214 files

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thanks for the detailed C/C++ import report. Triage: treating this as a C/C++ import extraction bug rather than expected behavior. Header includes are real dependency edges for impact analysis, and the current graph shape makes many active files look disconnected. Added to 0.9.1-rc; the fix should include a small C/C++ fixture for include-to-header IMPORTS edges and avoid confusing header targets with same-named module/source nodes.

[DeusData]

Root cause found — it's deeper than missing edge extraction, and your zero-inbound number now makes complete sense.

cbm_pipeline_fqn_compute strips file extensions when deriving qualified names, so a header and its same-stem source collide on both derived QNs:

• NodeController.h → module proj.NodeController, file proj.NodeController.__file__
• NodeController.cpp → module proj.NodeController, file proj.NodeController.__file__

Node upserts match by qualified name, so the header's File node is merged into the source's — the header ends up with no node of its own in the graph at all. Your #include "NodeController.h" IS extracted and resolved, but it lands on the shared module node (named after the .cpp), which is exactly what you observed. Every header with a same-stem sibling is invisible; that's the bulk of your 194/214.

Reproduced on your exact shape (main.cpp + NodeController.h/.cpp): the header has zero nodes and zero possible inbound edges. #1052 adds the reproduce-first test that stays RED until fixed.

Fix plan: headers get their own File-node identity and #include edges target it. One constraint makes this a careful change rather than a quick one: the module-QN unification between header and source is load-bearing for C/C++ call resolution (declaration↔definition joins), so only the File identity may split. It also touches the same code paths as #995 (in review), so it lands right after that to keep full and incremental builds consistent. Both are on the 0.9.1-rc milestone.

Thanks for the zero-inbound Cypher query — it's a genuinely useful detector for this class.