Hyperledger Composer 0.19.3客户端无法接收事件问题咨询

我之前在Composer 0.19.x搭配Fabric 1.1的项目里踩过这个坑，结合你基于digitalProperty示例的场景，给你梳理几个关键排查方向：

1. 先核对事件Hub的连接配置 #

很多时候这个报错都是因为事件Hub的URL配置错了：

• Fabric 1.1的peer默认事件端口是7053（grpc协议），别和peer的业务grpc端口7051搞混了。打开你的connection.json，确认eventUrl字段是正确的，比如：

  "eventUrl": "grpc://localhost:7053"
  

• 如果是多组织环境，务必确保你连接的peer是部署了目标链码的节点——没部署链码的peer不会转发链码事件，自然找不到可用的事件Hub。
• 如果你的Fabric集群开启了TLS，事件URL要改成grpcs://，同时要在connection配置里指定对应的TLS证书路径，不然连接会被拒绝。

2. 确认事件监听的注册时机 #

客户端必须在成功连接到业务网络之后，再注册事件监听。如果注册太早（比如businessNetworkConnection.connect()还没完成），peer还没完成链码的初始化绑定，就会报这个错。
参考digitalProperty示例的正确流程：

businessNetworkConnection.connect(connectionProfile, participantId, participantPwd)
  .then(() => {
    // 必须在连接成功后再注册监听
    return businessNetworkConnection.addListener('org.hyperledger.composer.system.TransactionEvent', (event) => {
      console.log('收到交易事件:', event);
    });
  })
  .catch((err) => {
    console.error('连接或监听失败:', err);
  });

3. 检查Fabric Peer的事件服务状态 #

登录到peer容器，查看peer的日志，确认事件服务是否正常启动：

docker logs peer0.org1.example.com

搜索日志里的event service关键词，如果看到类似Event service started的日志，说明服务正常；如果有报错（比如端口被占用、证书配置错误），要先修复peer的事件服务问题。

4. 验证链码事件的抛出逻辑 #

虽然REST服务器能看到事件，但还是要确认链码里的事件抛出是否正确：

• 链码交易函数里必须用stub.SetEvent()抛出事件，并且事件名称要和客户端监听的完全一致（大小写敏感）。比如：

  // 链码中抛出自定义事件
  err := stub.SetEvent("org.example.digitalPropertyNetwork.PropertyTransferredEvent", []byte(jsonPayload))
  if err != nil {
    return shim.Error(err.Error())
  }
  

• 客户端监听时要使用完整的事件类型名（包括命名空间），不能只写事件的简单名称。

5. 排查Composer客户端API的使用 #

Composer 0.19.x的事件监听有两种场景：

• 监听系统交易事件：用org.hyperledger.composer.system.TransactionEvent作为监听类型
• 监听自定义事件：用CTO文件中定义的完整事件类型名（比如org.example.digitalPropertyNetwork.PropertyTransferredEvent）
  别把事件类型名写错，否则客户端会找不到对应的事件源。

按照上面的步骤逐一排查，大部分情况下都能解决这个"找不到事件Hub"的问题。

内容的提问来源于stack exchange，提问作者Dennis Miller