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.
Version: 0.8.1 (linux-amd64-portable) · Setup: 24-repo fleet (Go + PHP + TypeScript) indexed into one store
Summary
CROSS_GRPC_CALLScan 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:<project-a>.gen.php.src.Echo_.EchoServiceClient.EchoService/SayHello<project-b>.gen.go.echo_service_grpc.pb.EchoService/SayHello<proto-repo>.gen.go.api.tenant.v1.service_grpc.pb.TenantService/GetTenantNo two of these can ever be equal, so
index_repository(mode=cross-repo-intelligence, target_projects=["*"])reportscross_grpc_calls: 0for 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->companyServiceorh.defaultGameSvcinstead of the proto service, which also defeats matching.)Suggestion
Canonicalize gRPC route identity to the proto fully-qualified
package.Service/Methodbefore rendezvous — it is derivable from generated code on both sides (PHPGrpc\BaseStubclients and Go_grpc.pb.goservice 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.