Call grpc.Invoke with nil "opts ...CallOption" throw a "invalid memory address or nil pointer dereference" and panics about grpc-go HOT 3 CLOSED

If you check the blame layer:

https://github.com/grpc/grpc-go/blame/master/stream.go#L280

None of this code has been touched at all for many years, so I don't think there is any regression here.

It's a programmer error to pass nil as a CallOption. It's not a situation that is difficult to avoid, and in fact it's very unusual to encounter it.

from grpc-go.

go.dev/ref/spec#Passing_arguments_to_..._parameters

I'm not seeing where it exactly talks about the nil handling there. I don't think Invoke() should handle nil being passed along opts.

For an example like https://go.dev/play/p/HxapK0toPq8 -

package main

import "fmt"

type CallOption interface {
	before(*string) error
	after(*string, *string)
}

type EmptyCallOption struct{}

func (EmptyCallOption) before(*string) error   { return nil }
func (EmptyCallOption) after(*string, *string) {}

func f(a ...CallOption) {
	fmt.Printf("%+v\n", a)
}

func main() {
	f()
	f(nil)
	f(EmptyCallOption{})
}

the output is:

[]
[<nil>]
[{}]

i.e., f() != f(nil)

from grpc-go.

I don't remember the gRPC package version we used before updating to Go v1.20, but before this update calling the Invoke method with the options set with nil doesn't panic, but after this update invoking the method results in a panic.

If the opts ...CallOption is nil. The panic occurs after the defer at https://github.com/grpc/grpc-go/blob/master/stream.go#L274 who is triggered by the calling one [nil] as a function without validation if the value is nil or not, at https://github.com/grpc/grpc-go/blob/master/stream.go#L280

from grpc-go.