使用Hyperledger Fabric Gateway调用QSCC的GetBlockByTxID接口报错：指定交易ID不在索引中

我看到你遇到的问题很典型：用CLI调用QSCC的GetBlockByTxID能正常查到交易对应的区块，但用fabric-gateway的Node.js代码调用就报错说交易ID不在索引里。结合你的代码和环境，我来帮你分析可能的原因和解决办法：

首先排查最可能的原因：网关连接的Peer节点没有该交易的索引 #

Fabric中每个Peer节点都会维护自己的交易索引，如果你的CLI和网关代码连接的不是同一个Peer，就可能出现这种差异：

• 你用CLI查询的Peer已经同步到了包含该交易的区块，所以能查到；但网关默认随机选择的背书Peer可能还没同步完成，或者根本没有该交易的副本（比如属于不同组织，且未同步区块）。

解决步骤：

1. 先确认你CLI使用的Peer节点（比如peer0.org1.example.com），然后修改网关代码，强制指定该Peer作为背书节点执行查询。
   示例代码修改：

   // 假设你已经在网关初始化时获取了目标Peer的对象（如peer0Org1）
   const result = await contract.evaluateTransaction(
     "GetBlockByTxID",
     network.getName(),
     txId,
     { endorsingPeers: [peer0Org1] } // 指定和CLI相同的Peer节点
   );
   

2. 检查各个Peer的区块高度是否一致，执行命令：

   peer channel getinfo -C mychannel
   

   如果网关连接的Peer区块高度低于CLI使用的Peer，说明区块同步还未完成，等待同步后再试，或者检查Peer的配置是否正常。

其次确认参数是否完全正确 #

虽然你说CLI能正常运行，但还是建议在代码里添加日志确认参数：

console.log(`当前查询的通道名：${network.getName()}，交易ID：${txId}`);

对比打印出的交易ID和CLI里的是否完全一致，避免因为URL参数转义、截断等问题导致传入了错误的交易ID。

其他排查点 #

• 交易是否已提交：虽然CLI能查到，但如果是刚提交的交易，网关调用时可能Peer还没完成写入，不过这种概率很低——毕竟CLI能查到就说明交易已经上链了。
• QSCC调用权限：系统链码QSCC默认允许所有合法身份调用，但如果你的网络自定义了ACL规则，可能限制了该身份的调用权限。不过你的报错是“交易ID不在索引中”，不是权限错误，所以这个可能性较低。

补充说明 #

你的代码逻辑本身是没问题的：调用QSCC的GetBlockByTxID接口的参数顺序（方法名、通道名、交易ID）和CLI一致，用Protobuf解码区块的方式也正确。核心问题大概率出在Peer节点的选择或同步上。

备注：内容来源于stack exchange，提问作者Rithick Guru