TestServiceClient.PingError causes panic

[floppyzedolfin]

Hello,
I'm testing a personal interceptor, and I realised that my test was crashing because the PingError method of the TestServiceClient panics in some conditions.

Here is the code I use to reproduce the issue:

package interceptor_test

import (
	"net"
	"testing"

	"github.com/grpc-ecosystem/go-grpc-middleware/v2/testing/testpb"
	"google.golang.org/grpc"
	"google.golang.org/grpc/credentials/insecure"
)

func TestInterceptor(t *testing.T) {
	lstConfig := net.ListenConfig{}

	serverListener, err := lstConfig.Listen(t.Context(), "tcp", "")
	if err != nil {
		t.Fatalf("failed to listen: %v", err)
	}

	srv := grpc.NewServer()
	testpb.RegisterTestServiceServer(srv, &testpb.TestPingService{})

	go func() {
		err := srv.Serve(serverListener)
		if err != nil {
			panic(err)
		}
	}()

	grpcClientConn, err := grpc.NewClient(
		serverListener.Addr().String(),
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)
	if err != nil {
		t.Fatalf("failed to connect: %v", err)
	}

	cli := testpb.NewTestServiceClient(grpcClientConn)

	defer func() {
		srv.Stop()
	}()

	_, err = cli.PingError(t.Context(), &testpb.PingErrorRequest{
		Value: "hello",
	})
	if err != nil {
		t.Fatal("calling Ping Err:", err.Error())
	}
}

Here is the output of running this test:

▶ go test ./...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x8d6b35]

goroutine 22 [running]:
github.com/grpc-ecosystem/go-grpc-middleware/v2/testing/testpb.(*wrappedErrFields).Error(0xc0002146c0?)
	/home/pascal/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.3.2/testing/testpb/interceptor_suite.go:164 +0x15
google.golang.org/grpc/status.FromError({0xb3b2e0, 0xc0002146c0})
	/home/pascal/go/pkg/mod/google.golang.org/grpc@v1.74.2/status/status.go:108 +0xd3
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000184400, {0xb3f608, 0xc000214600}, 0xc00022e180, 0xc0001b26f0, 0xf4bed0, 0x0)
	/home/pascal/go/pkg/mod/google.golang.org/grpc@v1.74.2/server.go:1433 +0x13d5
google.golang.org/grpc.(*Server).handleStream(0xc000184400, {0xb3f8b8, 0xc000144000}, 0xc00022e180)
	/home/pascal/go/pkg/mod/google.golang.org/grpc@v1.74.2/server.go:1841 +0xb95
google.golang.org/grpc.(*Server).serveStreams.func2.1()
	/home/pascal/go/pkg/mod/google.golang.org/grpc@v1.74.2/server.go:1061 +0x7f
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 52
	/home/pascal/go/pkg/mod/google.golang.org/grpc@v1.74.2/server.go:1072 +0x11d
FAIL	github.com/pascal/awesomeProject1	0.013s
FAIL

The bottomline is the call to New(codes.Unknown, err.Error()) in status.go with a err == nil variable.

func (err *wrappedErrFields) Error() string {
	// Ideally we print wrapped fields as well
	return err.wrappedErr.Error()
}

Here are the contents of my go.mod:

module github.com/pascal/awesomeProject1

go 1.25

require (
	github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.2
	google.golang.org/grpc v1.74.2
)

require (
	github.com/davecgh/go-spew v1.1.1 // indirect
	github.com/pmezard/go-difflib v1.0.0 // indirect
	github.com/stretchr/testify v1.10.0 // indirect
	golang.org/x/net v0.40.0 // indirect
	golang.org/x/sys v0.33.0 // indirect
	golang.org/x/text v0.25.0 // indirect
	google.golang.org/genproto/googleapis/rpc v0.0.0-20250528174236-200df99c418a // indirect
	google.golang.org/protobuf v1.36.7 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
)

I don't know if this issue should be with the go-grpc-middleware team, or if it should be with the golang.org/grpc team.

[johanbrandhorst]

Thanks for this report. I'm not sure I understand, is the service definition in this repo or in the grpc repo? If it's one of our tests or examples it's up to us to fix it, but if not, it might be worth reporting this in the gRPC repo, as you suggest.

[floppyzedolfin]

My repo is just about having an interceptor that does what I want (my interceptor logs the code that is returned by the handler). I discovered that the PingError doesn't return a "proper" grpc reponse+error, which cause the panic above. I removed my interceptor from this example because

1. it was adding unnecessary code to this report
2. the issue happens regardless of if I use my interceptor.

My platform won't be calling PingError, but since my repo is only about the interceptor, I figured I could use PingError anyways and check that my interceptor was doing its job.

Here's a short version of my interceptor, for what it's worth:

func ErrorLoggerInterceptor(w  io.Writer) grpc.UnaryServerInterceptor {
	return func(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
		resp, err :=  handler(ctx, req)
		
		_, _ = fmt.Fprintf(w, "error is: %s", err.Error())
		
		return resp, err
	}
}

and I would use it this way:

	srv := grpc.NewServer(
		grpc.ChainUnaryInterceptor(
			ErrorLoggerInterceptor(os.Stderr),
			// Other interceptors
		),
	)

But since my interceptor doesn't cause the initial panic, I figured I'd trim it out to get to a smaller version of the code reproducing the issue.

[floppyzedolfin]

I think, deep down, that my issue is the following:

func (s *TestPingService) PingError(_ context.Context, ping *PingErrorRequest) (*PingErrorResponse, error) {
	code := codes.Code(ping.ErrorCodeReturned)
	return nil, WrapFieldsInError(status.Error(code, "Userspace error"), []any{"error-field", "plop"})
}

This wraps a GRPC error into a non-GRPC error - it is not possible to call status.FromError() on the returned error. I think, in my case, I expected nil here -but I'm not sure.

[johanbrandhorst]

You expected PingError to return a nil error? I'm still not sure I understand. If you think there is a bug here, would you mind opening a PR with a fix and we can discuss the merits in there? Thank you

[johanbrandhorst]

Oops, sorry, didn't mean to close the issue

[floppyzedolfin]

Ah, I think I know what's wrong with what I did: I didn't provide an ErrorCodeReturned to my PingError call. I'll be sending a PR to avoid the panic from happening for other users.

[floppyzedolfin]

PR: #795