Shinami 排查已有 Sui 赞助记录：COMPLETE、过期与 HTTP200 错误
链小知 · 进阶 · 核验 · 依官方文档整理
将 gas_getSponsoredTransactionBlockStatus 和既有错误记录分开解释，避免把代付 gas 已使用视为业务交易成功。
开始前准备
- 准备已有脱敏 Sui 赞助记录：gas_sponsorTransactionBlock 返回的 txDigest、expireAtTime、绑定网络/fund、时间，以及随后状态查询或错误记录。
- 如需判断交易结果，另准备同网络已有执行 effects 记录；仅有 Gas Station 状态时只做赞助状态分类，不重新签名、提交或扩大权限。
1. 确认 digest 与记录出处
状态方法 gas_getSponsoredTransactionBlockStatus 需要 gas_sponsorTransactionBlock 返回的 Base58 transactionDigest。参数是一项 digest，不是 sender、depositAddress 或 txBytes。
将查询所用资金池和网络与原赞助配置对应；该方法判断的是请求 key 所绑定 fund 的 gas，不是全网任意赞助查询。
检查结果：digest 格式和原赞助记录可对应，网络/fund 一致；不保留或展示密钥、签名。
2. 区分 HTTP 与 JSON-RPC 错误
先读 HTTP 状态和 JSON error.code/message，再读 result。Shinami 的 JSON-RPC 错误会在 HTTP200 中返回，API Insights 也单列这类错误。
-32010 为 QPS 限制，应将退避策略交给后端；-32012 为当前时段资源上限，同一时段立即重复不会解决。401 应核权限与 allowlist，不能当作 digest 无效。
检查结果：没有把 HTTP200 当业务成功；每条错误有准确类别和待核原因。
3. 核对 IN_FLIGHT 与过期时间
IN_FLIGHT 表示 gas 已分配且 expireAtTime 尚未达到，执行尝试尚未发生。它不证明用户已签名或交易已广播。
expireAtTime 单位是 Unix 秒，官方此方法赞助在创建后一小时过期。比较记录自身查询时间，避免用本机当前时间判断过去快照是否已经过期。
检查结果：时间单位、快照时刻与状态一致；保留未执行而非“已到账”的解释。
4. 保留 INVALID 的不同原因
INVALID 既可能是此 fund 未找到相应已赞助 gas，也可能已达 expireAtTime 且仍未消耗。先核原赞助、fund 和时间，再写明确或未确定原因。
Completed transactions 也含未使用而过期的赞助，列表仅最后14天与10000条；界面未找到记录时，应结合覆盖期，不直接断言全网无该交易。
检查结果：INVALID 未被单一解释为交易失败，查找范围与历史限制已写入结论。
5. 分开判断 COMPLETE 与执行结果
COMPLETE 仅表示曾尝试执行并消耗所附 gas，官方明确不保证成功。仅有该值时结论写“赞助 gas 已使用，交易业务结果待核”。
有同网络既有 effects 时，再匹配交易 digest 与实际执行状态；不要使用 Gas 文档残留的 Shinami Node Service 链接重新执行，因为当前公告已将该节点产品退役。
检查结果：赞助状态和交易结果分为两个字段；缺执行证据时不推导收款、合约结果或退款。
6. 按 Sui 错误生成排查清单
如既有赞助错误为 -2 Insufficient fund balance，核查当时余额与 inFlight；-1 Gas object unavailable 属于 gas 对象供应问题；-32602 则按 message 核预算范围或禁止使用 gas 对象的参数。
同数值在 Aptos Gas Station 含义不同，必须按 Sui 部分阅读。整理时间、digest、network/fund、错误、状态和证据缺口，由已有管理员流程处理，不在本流程重试赞助或增加权限。
检查结果：每条建议对应具体 Sui 错误和已有记录，未混用链别或从状态升级为执行证明。
怎样确认完成
- 已分别记录赞助生命周期、错误类别和可核交易结果，未确定原因明确保留。
- 本教程仅依据文档解释已有记录，没有认证 API、签名、提交或服务实测。
常见错误与边界
- COMPLETE 与控制台 Completed 列表都不等同所有业务成功。
- 将 INVALID 一律归因于用户签名失败，忽略资金池和过期。
- 用旧 Node URL、其它链的同号错误或实时重复赞助填补证据缺口。