fix: prevent rpc client panic on rpc response if ProducerReady is nil

[sekfung]

Motivation

prevent rpc client panic on rpc response if ProducerReady is nil

Modifications

use ProducerSuccess.GetProducerReady instead of ProducerSuccess.ProducerReady

panic log

panic: runtime error: invalid memory address or nil pointer dereference

 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xe997de]

 goroutine 982 [running]:

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).internalReceivedCommand(0xc0005d0840, 0xc0010a6000, {0x0?, 0x0})

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:526 +0x1de

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).run(0xc0005d0840)

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:420 +0x3b0

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).start.func1()

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:231 +0x65

 created by github.com/apache/pulsar-client-go/pulsar/internal.(*connection).start

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:227 +0x70

 panic: runtime error: invalid memory address or nil pointer dereference

 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xe997de]

 
goroutine 989 [running]:

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).internalReceivedCommand(0xc0005d1080, 0xc0004f4600, {0x0?, 0x0})

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:526 +0x1de

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).run(0xc0005d1080)

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:420 +0x3b0

 github.com/apache/pulsar-client-go/pulsar/internal.(*connection).start.func1()

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:231 +0x65

 created by github.com/apache/pulsar-client-go/pulsar/internal.(*connection).start

 	/go/pkg/mod/github.com/apache/pulsar-client-go@v0.9.1-0.20230301160414-42ded0d59c46/pulsar/internal/connection.go:227 +0x70

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API: (yes / no)
• The schema: (yes / no / don't know)
• The default values of configurations: (yes / no)
• The wire protocol: (yes / no)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / GoDocs / not documented)
• If a feature is not applicable for documentation, explain why?
• If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

[sekfung]

/pulsarbot run-failure-checks

[sekfung]

seems like CI failed

[BewareMyPower]

Could you show how to reproduce it? In which case could this field be nil? We should not perform nil checks everywhere. It could hide some potential bugs.

[sekfung]

@BewareMyPower Yes, you're right.

Pulsar Broker: v2.7.4

I just created a simple producer to send messages on an existed topic, and it worked with v0.9.0. However, after upgrading the pulsar-client-go to the master branch, I encountered a panic error. It appears that the panic is related to PR #958

I don't know why the producer_ready is always nil. Even if performing nil checks, such as this one, the client would wait indefinitely, since timeoutCh = nil

if res.error == nil && *res.RPCResult.Response.Type == pb.BaseCommand_PRODUCER_SUCCESS {
	if res.RPCResult.Response.ProducerSuccess.ProducerReady == nil {
		timeoutCh = nil
		break
	}
}

My modifications involve using ProducerSuccess.GetProducerReady() instead of ProducerSuccess.ProducerReady, which would always return true and prevent a panic when producer_ready is nil

[BewareMyPower]

The reason is that the producer_ready field was introduced first in Pulsar 2.8.0, see apache/pulsar#8992.

I just see the default value of GetProducerReady is true now. So this PR LGTM.

[sekfung]

The reason is that the producer_ready field was introduced first in Pulsar 2.8.0, see apache/pulsar#8992.

I just see the default value of GetProducerReady is true now. So this PR LGTM.

@BewareMyPower Thanks for solving my doubts