Index out of bounds when using gRPC UnaryCallInterceptor

[stefanprisca]

I tried out the new gRPC UnaryClientInterceptor, and got this error when making a call from the client:

panic: runtime error: index out of range [1] with length 0

goroutine 1 [running]:
go.opentelemetry.io/otel/plugin/grpctrace.serviceFromFullMethod(0x9b7ae8, 0x12, 0x2, 0xc0000ad260)
/home/stefan/go/pkg/mod/go.opentelemetry.io/otel@v0.4.3/plugin/grpctrace/interceptor.go:434 +0xc2
go.opentelemetry.io/otel/plugin/grpctrace.UnaryClientInterceptor.func1(0xa74aa0, 0xc0000a2000, 0x9b7ae8, 0x12, 0x974260, 0xc0000c6f40, 0x974360, 0xc000150f30, 0xc00019c380, 0x9d4c60, ...)
/home/stefan/go/pkg/mod/go.opentelemetry.io/otel@v0.4.3/plugin/grpctrace/interceptor.go:77 +0x1bc

I believe that the issue is with the regexp used to extract the service name from the full gRPC method name:
^/\S*\.(\S*)/\S*$ which seems to look for a fully qualified service name.
In my case, the full method name is simply /Lightpeer/Persist, so the regexp won't find anything.

I'm not sure if this is an issue on my side or not, but a possible fix can be to replace the regexp with ^/(?:\S*\.)?(\S*)/\S*$, making it optional to have a fully qualified service name. Specifically, see this commit.

[stefanprisca]

I'm looking now at the specification and it says that

Span name MUST be full gRPC method name formatted as: $package.$service/$method

Is this some hard requirement? Because in this case there might be something wrong on my side (maybe when generating the grpc packages?)

[MrAlias]

I'm looking now at the specification and it says that

Span name MUST be full gRPC method name formatted as: $package.$service/$method

Is this some hard requirement? Because in this case there might be something wrong on my side (maybe when generating the grpc packages?)

It looks like the spec is incorrect in that normative assertion. The gRPC protocol does not define the service name in that fashion. It seems like an added restriction of the OpenTelemetry specification, and I don't think it is justified.

I'll open an Issue there.

[kevinjqiu]

I'm hitting this issue as well. Is there a workaround in the meantime?

EDIT: I guess the workaround is to do what @stefanprisca did and use the replace directly in my go.mod file.