We are using the IBM Managed Blockchain based on fabric 1.2, and using the Go SDK @5e291d3a34f59beb9a8ae2bcbba388515648dc73. When we try to invoke the chaincode we have installed on the peers, we get a "no peers to connect to" error:
[fabsdk/fab] 2019/01/25 12:25:57 UTC - dispatcher.(*Dispatcher).Start.func1 -> DEBU Listening for events...
[fabsdk/fab] 2019/01/25 12:25:57 UTC - client.(*Client).connect -> DEBU ... got error in connection response: no peers to connect to
[fabsdk/common] 2019/01/25 12:25:57 UTC - retry.(*RetryableInvoker).Invoke -> DEBU Failed with err [error registering for TxStatus event: no peers to connect to] on attempt #1. Checking if retry is warranted...
[fabsdk/util] 2019/01/25 12:25:57 UTC - lazyref.(*Reference).setTimerRunning -> DEBU Timer started
[fabsdk/common] 2019/01/25 12:25:57 UTC - retry.(*RetryableInvoker).Invoke -> DEBU ... retry for err [error registering for TxStatus event: no peers to connect to] is NOT warranted after 1 attempt(s).
[fabsdk/util] 2019/01/25 12:25:57 UTC - lazyref.checkTimeStarted -> DEBU Starting timer
After putting some extra logging of our own it looks like the failure happens because the peer discovery service (https://github.com/hyperledger/fabric-sdk-go/blob/master/pkg/client/common/discovery/dynamicdiscovery/chservice.go#L72) doesn't return any peers in its response. The targets seem to be set correctly.
After dumping the GRPC response, we get
(*discovery.Response)(0xc4205cd600)(
results: <
members: <
peers_by_org: <
key: "org1"
value: <>
>
>
>
)
We also set up a different fabric network on our own with the same chaincode, which works properly and the same dump shows this instead (some parts were redacted):
(*discovery.Response)(0xc42045ed20)(
results: <
members: <
peers_by_org: <
key: "Org1MSP"
value: <
peers: <
state_info: <
payload:"<redacted>"
>
membership_info: <payload:"<redacted>" >
identity:"<redacted>"
>
peers: <
state_info: <
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
signature:"<redacted>"
>
identity:"<redacted>"
>
>
>
peers_by_org: <
key:"Org2MSP"
value: <
peers: <
state_info:<
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
>
identity:"<redacted>"
>
peers: <
state_info: <
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
signature:"<redacted>"
>
identity:"<redacted>"
>
>
>
>
>
)
I am unsure if the issue is in the configuration of the SDK or the IBM Managed fabric network. If it is the IBM network, then it seems that somehow the peers aren't aware that they are members of an organization.
Has anyone seen this behaviour before? I searched the hyperledger official rocket chat for the "no peers to connect to" error, and some results came up, but they seemed to be caused by other reasons, such as the peers being excluded by the SDK, not due to the response to the discovery request.
