Go services get 0 cross-repo edges (Fiber route paths empty, gRPC not captured)

[RawSalmon69]

Same problem as #678 and #523 (Route path comes out empty, so the matcher has nothing to compare against), but on Go, where it's total. I ran cross-repo-intelligence over a private ~50-service Go platform and got 0 edges in every category. #678 is FastAPI and #523 is generic, and #292 lists Go as a target, so here are the Go specifics.

Setup

• ~38 Go backends. Fiber v2 for HTTP, gRPC generated stubs for service-to-service, Kafka for events and Debezium CDC.
• 7 JS/TS frontends (Vite/React, Next, Astro) calling the backends over REST with axios.
• 49 repos indexed, each its own project in the shared store. The cross pass reports projects_scanned: 50, so it sees all of them.
• codebase-memory-mcp 0.8.1, static binary, macOS arm64.

Result

cross-repo-intelligence from any source repo with target_projects: ["*"]:

{"cross_http_calls":0,"cross_async_calls":0,"cross_channel":0,"cross_grpc_calls":0,"total_cross_edges":0}

Same on mode: fast and mode: full.

Cause

Go HTTP routes have no path. Every Route node on a Fiber service has the verb but an empty key_path:

MATCH (r:Route) RETURN r.method, r.key_path LIMIT 5
"GET"   ""
"POST"  ""
"PATCH" ""

MATCH (r:Route) WHERE r.key_path <> '' returns nothing for the whole project. Same as #678, different framework. Fiber builds the path from app.Group("/admin") plus grp.Post("/x"), so the full path is never one literal at the registration site.

gRPC isn't captured at all, and it's the main backend-to-backend protocol here. Services call each other through generated stubs like pb.NewOrderServiceClient(conn).GetOrder(ctx, req), with the address coming from an env var (ORDER_SERVICE_ADDR). No CROSS_GRPC_CALLS get emitted. The proto FQN is a clean key for this. Contracts are vendored per repo under proto/, and orderpb.OrderService/GetOrder is the same string on caller and callee even when the .proto files have drifted apart. The address is useless to match on (it's a localhost env var); the FQN isn't. This is the Tier-1 case in #292. #294 (the emit_grpc_edge pollution bug) is fixed now, but a Go repo still gives cross_grpc_calls: 0.

Frontends are fine, the backends are where it breaks. The JS frontends populate HTTP_CALLS.url_path (one had 17 calls like /admin/customers/:id). With the backend route paths empty there's nothing to join to. And even with paths filled, this platform sits behind an API gateway that rewrites paths and mounts each service at its own root, so picking the right target service needs the caller's axios baseURL too, not just the path string.

Kafka. A lot of the wiring is Kafka: event topics and Debezium CDC (dbz.mongo.* topics). MATCH (c:Channel) returns 0 on the consumers. Channels are Socket.IO/EventEmitter today and broker support is the #652 / #292 Tier-2 track, so I'm not asking for it here. Just noting HTTP plus gRPC alone won't fully connect a platform shaped like this.

Repro

1. Index a Go Fiber service (fast or full).
2. MATCH (r:Route) WHERE r.key_path <> '' RETURN count(r) gives 0.
3. Index a second Go service that calls it through a generated gRPC client.
4. cross-repo-intelligence from the second repo with target_projects: ["*"] gives total_cross_edges: 0.

Fixes that would help, in order

1. Fill Route path for Go HTTP frameworks. Fiber first, Gin/Echo/chi are similar. Resolve the router-group prefix into the full path. Also helps cross-repo-intelligence: 0 edges for FastAPI backend — Route.path empty, router prefix stripped #678 and cross-repo-intelligence returns 0 edges for a byte-identical call/route #523.
2. Emit gRPC handler Routes and GRPC_CALLS keyed by proto FQN (pkg.Service/Method), from .proto / generated *.pb.go and from the generated client stub call sites. Protocol-aware cross-repo intelligence: gRPC + typed-message + attribute-route matching (design proposal) #292 Tier 1.
3. Kafka topic matching later (Protocol-aware cross-repo intelligence: gRPC + typed-message + attribute-route matching (design proposal) #292 Tier 2 / feat(pipeline): NATS subject detection for cross-repo ASYNC_CALLS edges (Tier 2 follow-up to #292) #652).

Can share graph dumps or test a build.

[DeusData]

Thanks, this is a strong report. I’ve triaged it under #592 and #398. Treating Fiber route path resolution as the bug portion, gRPC proto-FQN linking as the #292 Tier-1 path, and Kafka as the later Tier-2 follow-up. Next step is a minimal public Fiber + proto fixture so the route-path and gRPC cases can be guarded independently.