Hyperledger Fabric批量执行chaincode invoke报错逐次执行正常如何排查

问题原因确认 #

你的怀疑是对的，问题确实出在交易提交后的状态同步延迟上。
Hyperledger Fabric 的 peer chaincode invoke 命令默认仅在交易被排序节点成功接收后就返回成功输出，不会等待交易被打包出块、同步到节点账本后再返回。你提到的第四条openCashDesk逻辑明显依赖第三条openStore的执行结果，批量并行调用时，第四条请求发出时第三条交易还未完成落账同步，链码读取到的门店状态仍为未开启，自然会抛出校验错误。

排查步骤 #

• 首先给所有invoke命令加上--waitForEvent参数，该参数会强制命令阻塞到交易被确认提交到账本后再返回，修改后再批量执行命令，确认是否还会报错：

  peer chaincode invoke -C mychannel -n basic -c '{"function":"createStore","Args":["1","Target","Weyburn","false"]}' --waitForEvent
  peer chaincode invoke -C mychannel -n basic -c '{"function":"createCashDesk","Args":["1","1","false"]}' --waitForEvent
  peer chaincode invoke -C mychannel -n basic -c '{"function":"openStore","Args":["1"]}' --waitForEvent
  peer chaincode invoke -C mychannel -n basic -c '{"function":"openCashDesk","Args":["1"]}' --waitForEvent
  

• 提取报错命令的详细错误信息，确认是否为逻辑校验类错误（比如门店未开启），进一步验证依赖缺失问题。
• 执行完第三条命令后立刻调用peer chaincode query查询门店状态，对比延迟几秒后查询的结果，可直接确认同步延迟是否存在。

Fabric 出块控制方法 #

Fabric 没有以太坊类公链的手动出块机制，出块逻辑由排序节点的配置控制，测试网络默认使用的etcdraft排序服务可通过修改以下两个参数控制出块逻辑：

1. BatchTimeout：批量出块的超时时间，默认2秒，达到该时长即使块内交易数未达阈值也会出块
2. BatchSize.MaxMessageCount：单个区块的最大交易数，达到该数值立刻出块

你如果要让交易处于挂起状态，只需要修改排序节点配置，把BatchTimeout调整为一个极大值（比如1h），同时把MaxMessageCount调整为远大于你要提交的交易数的数值，交易就会缓存在排序节点中不会被打包，直到你主动调整配置触发出块条件即可。

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