invalid memory address or nil pointer dereference on v7@v7.17.7/elasticsearch.go:307

[defornia]

I've caught a panic from k8s log as belows.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x114653f]

goroutine 587 [running]:
github.com/elastic/go-elasticsearch/v7.(*Client).Perform(0xc000add000, 0xc002b338c0)
	/go/pkg/mod/github.com/elastic/go-elasticsearch/v7@v7.17.7/elasticsearch.go:307 +0x9f
github.com/elastic/go-elasticsearch/v7/esapi.UpdateByQueryRequest.Do({{0xc002bfbce0, 0x1, 0x1}, {0x0, 0x0, 0x0}, {0x2c68fe0, 0xc000052c40}, 0x0, {0x0, ...}, ...}, ...)
	/go/pkg/mod/github.com/elastic/go-elasticsearch/v7@v7.17.7/esapi/api.update_by_query.go:304 +0x1caa
github.com/elastic/go-elasticsearch/v7/esapi.New.newUpdateByQueryFunc.func101({0xc002bfbce0, 0x1, 0x1}, {0xc000052c60, 0x4, 0x495f8a?})
	/go/pkg/mod/github.com/elastic/go-elasticsearch/v7@v7.17.7/esapi/api.update_by_query.go:39 +0x14b

The method is as belows.

// Perform delegates to Transport to execute a request and return a response.
//
func (c *Client) Perform(req *http.Request) (*http.Response, error) {
	// ProductCheck validation. We skip this validation of we only want the
	// header validation. ResponseCheck path continues after original request.
	if !c.useResponseCheckOnly {
		// Launch product check for 7.x, request info, check header then payload.
		if err := c.doProductCheck(req.Context(), c.productCheck); err != nil {
			return nil, err
		}
	}

	// Retrieve the original request.
	res, err := c.Transport.Perform(req)

	// ResponseCheck path continues, we run the header check on the first answer from ES.
	if err == nil && (res.StatusCode >= 200 && res.StatusCode < 300){
		checkHeader := func(context.Context) error {
			return genuineCheckHeader(res.Header)
		}
		if err := c.doProductCheck(req.Context(), checkHeader); err != nil {
			res.Body.Close()
			return nil, err
		}
	}
	return res, err
}

There might be an issue where the code does not check if res is nil before accessing res.StatusCode, which could lead to the panic.