Repository navigation
cross-repo-intelligence: gRPC route identities are project/namespace-prefixed, so CROSS_GRPC_CALLS can never match across languages #953
Description
Version: 0.8.1 (linux-amd64-portable) · Setup: 24-repo fleet (Go + PHP + TypeScript) indexed into one store
Summary
CROSS_GRPC_CALLS can structurally never match across languages: gRPC route identities embed the project name and generated-code namespace of whichever side they were extracted from, and rendezvous matching is exact on that string.
Observed
The same proto contract (EchoService/SayHello) yields these route identities:
| Side | Route identity |
|---|---|
| PHP client (project A) | <project-a>.gen.php.src.Echo_.EchoServiceClient.EchoService/SayHello |
| Go server (project B) | <project-b>.gen.go.echo_service_grpc.pb.EchoService/SayHello |
| Proto registry repo | <proto-repo>.gen.go.api.tenant.v1.service_grpc.pb.TenantService/GetTenant |
No two of these can ever be equal, so index_repository(mode=cross-repo-intelligence, target_projects=["*"]) reports cross_grpc_calls: 0 for every project — it scans all 24 projects in ~60 ms/repo and links nothing, despite live gRPC traffic between 6 of them.
(Separately, some client-side edges carry variable-derived service names like $this->companyService or h.defaultGameSvc instead of the proto service, which also defeats matching.)
Suggestion
Canonicalize gRPC route identity to the proto fully-qualified package.Service/Method before rendezvous — it is derivable from generated code on both sides (PHP Grpc\BaseStub clients and Go _grpc.pb.go service descriptors both embed the full method path, e.g. /api.tenant.v1.TenantService/GetTenant). This would be the gRPC analog of the __route__METHOD__{path} canonicalization already applied to HTTP routes.
Activity
DeusData commentedon Jul 8, 2026
Thanks for the clear cross-language gRPC reproduction. Triage: this looks like a real identity-normalization bug in CROSS_GRPC_CALLS, not something v0.9.0 explicitly claims to solve. The fix likely needs canonical proto service/method identities across projects and languages, so keeping this open under parsing quality.
DeusData commentedon Oct 19, 2026
Thank you again for the concrete client/server route identities. They give this report enough detail for follow-up without another broad information request. I have no newly verified fix to report for the cross-language gRPC matching case; the canonical-identity question remains the specific work described here.