Repository navigation
Java: interface methods emitted twice — as both Method and Function nodes (472 spurious Function nodes) #1234
Description
Environment
- codebase-memory-mcp 0.9.0 (macOS arm64, Darwin 25.0.0)
- Project: Java 21 / Spring Boot 3 monorepo, ~1,358 Java files, indexed in full mode (20,530 nodes / 70,485 edges)
Summary
Methods declared on Java interfaces are emitted as two nodes: a Method (correct, with parent_class) and a duplicate Function node at the same file/line. Java has no free-standing functions, so any Function node in a .java file is spurious. Our graph has 472 Function nodes pointing into .java files.
Repro
Source (MarketplaceReservationService.java, an interface):
ReservationResponseDTO createReservation(Authentication authentication, ReservationRequestDTO request);Cypher:
MATCH (m) WHERE m.name = 'createReservation' RETURN m.qualified_name, labels(m)Result contains both:
...reservation.service.MarketplaceReservationService.createReservation ["Method"]
...reservation.service.createReservation ["Function"] <- duplicate, same file/line
Aggregate check:
MATCH (f:Function) WHERE f.file_path ENDS WITH '.java' RETURN count(f) // 472Impact
- Search results show doubled entries for interface methods.
- Node/label counts and any per-label analytics are skewed.
- Structural boosting in BM25 (Functions +10) double-boosts these phantoms.
Notes
Looks like the interface-body visitor emits the method both under the parent type and at file scope. Happy to test a fix.
Activity
DeusData commentedon Jul 24, 2026
Confirmed as an extraction invariant: Java interface members are methods, and the same source span must not also produce a top-level Function node. The RED should assert one Method node for the interface declaration and zero Function nodes at the same file and line before testing aggregate counts. High priority for
0.9.1-rcunder #592.harshitaajoshi commentedon Jul 29, 2026
I would like to work on this. I traced the root cause to
push_class_body_children()ininternal/cbm/extract_defs.c: it does not recognizeinterface_bodyas a class body container (unlikefind_class_body(), which already does), so the fallback path pushesmethod_declarationchildren back onto the walk stack andextract_func_def()mints a duplicate Function node.I'll add
interface_body(andenum_bodyfor the same class of bug) to the body container check, with a reproduce-first regression test that asserts one Method node and zero same-line Function nodes for interface methods.fix(extract): prevent duplicate Function nodes for Java interface met…
fix(extract): merge-dedup Function nodes into Method nodes, preservin…
fix(extract): merge-dedup Function nodes into Method nodes, preservin…
DeusData commentedon Aug 4, 2026
Fixed on main: 87a0e3f made class-body routing language-agnostic, so Java interface/enum methods are extracted once as Method nodes — the duplicate top-level Function nodes (the 472 spurious nodes you counted) are gone. We verified against current main with dedicated regression tests, landing via #1433 (distilled from @harshitaajoshi's #1327): they pass on main and reproduce your exact symptom (duplicate Function nodes) the moment the routing regresses.
Thank you for the precise report — the node counts and the interface/enum split made this easy to pin down and to bind in the suite.
Merge pull request #1433 from DeusData/test/1234-java-interface-enum-…
test(extract): bind the Java interface/enum method dedup fix (DeusDat…