如何解决Graph Protocol/graph-node在Huobi ECO Chain上的(-32000 missing trie node)错误

这个报错不属于graph-node自身的程序运行故障，本质是graph-node对接的Heco链RPC节点存在状态存储不完整/损坏的问题：
以太坊兼容链的全节点通过Merkle Trie存储账户状态、合约存储数据，当节点执行历史高度的eth_call请求时，需要从本地存储的Trie树中检索对应路径的节点数据，如果本地缺失对应哈希的Trie节点，就会抛出-32000 ServerError: missing trie node的报错，和graph-node的同步逻辑、子graph代码没有直接关联。

• 第一步：手动复现验证故障点
  直接向graph-node当前配置的Heco RPC地址发送和graph-node完全一致的调用请求：指定区块高度为867157，调用日志中记录的合约地址0xc32c…b719的对应方法，检查是否复现完全相同的missing trie node报错。如果手动调用即可触发故障，即可排除graph-node侧的配置问题，确认故障出在RPC节点。
  常见的RPC端故障诱因包括：为节省磁盘空间开启过度剪枝，删除了对应历史区块的状态Trie数据；节点同步过程中状态数据库落盘损坏，未做一致性校验就开启RPC服务；节点版本存在兼容性bug，对历史区块的状态查询返回异常。
• 第二步：修复RPC节点的状态问题
  如果你使用的是自行部署的Heco全节点作为RPC后端：
  • 调整节点启动配置，不要开启过度剪枝模式，保证节点存储的状态数据覆盖范围不小于子graph配置的起始区块高度到当前链最高高度的全部区间，满足Graph节点的历史状态查询需求
  • 若已经出现状态数据损坏、剪枝过度导致的缺失，清空节点本地的状态数据库，从可信的全节点快照重新同步状态数据，待节点同步高度超过当前卡住的867157区块后，再开放RPC服务
  • 升级节点到官方维护的稳定版本，避免使用社区魔改的旧版本节点，减少历史查询的随机报错
    如果你使用的是第三方公共RPC节点：
    直接替换为支持完整历史状态查询的Heco RPC端点，避免选择对历史状态做了极致剪枝、无完整数据存储的公共节点。
• 第三步：graph-node侧的同步恢复
  替换/修复好RPC节点后，无需重置graph-node的全部同步进度，只需针对日志中卡住的子graph（ID: QmTXfVewLoDqTjj2kT2Fofb1kh8tYr7yHmPjzLJCs2VFzy），将同步高度重置到故障区块的前一个位置，触发子graph从该断点继续同步即可。
  注意给graph-node配置RPC时，避免使用多节点负载均衡的公共RPC地址，否则会出现不同请求路由到状态不一致的不同节点上，频繁触发Trie节点缺失的异常，最好为graph-node配置单节点、状态一致的专用RPC服务。

部分Heco链早期版本的节点存在随机报错问题，即使状态存储完整，查询部分历史高度的eth_call请求时也会返回无依据的Trie缺失提示，这类情况只需升级节点到稳定版本，或者切换到其他状态一致的RPC端点即可恢复。

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