Ostium订单提交了却查不到：分清Pending、取消、成交与两种历史格式
链小知 · 进阶 · 核验 · 依官方文档整理
用已有SDK/REST材料区分提交ID、执行ID、时间过滤与净返还字段，避免空历史等于订单不存在。
开始前准备
- 准备本人原订单的交易hash/keeper order id、trader地址、环境、pair/方向、时间及已保存的SDK响应或REST历史回执；不调用业务接口补样本。
- 本文比较当前getOrders文档与Builder REST /v1/orders 1.0.0 schema，SDK具体安装版本未核；先保留原接口/版本，不将源码字段混为链上事件ABI。
1. 标明原材料来自哪一种接口
先在原材料写明SDK getOrders还是Builder REST GET /v1/orders，原trader与chainId。REST参数42161是Arbitrum生产、421614是Sepolia，响应chainId也要对上；测试回执不证明生产订单存在。
SDK按hash/keeper id查询并可包含pending；REST历史只含已执行或取消行。两个都叫orders，不能因为REST没有行就重发或断言原提交不存在。
检查结果：接口、环境、trader身份确定，未知版本未强行套字段。
2. 匹配订单ID与提交交易
SDK orderIds是on-chain keeper order id，响应oid为十进制字符串；initiatedTxHashes按提交交易定位。两过滤参数互斥，先核原请求有没有同时使用。
REST id是subgraph row id，tradeID是交易slot、limitID是原挂单身份；它们不等SDK oid。按原trader、pair和提交/执行tx共同关联，不能仅见一个数字相同就并单。
检查结果：keeper id、row id、slot和hash分别列明，跨格式关联有依据。
3. 先区分Pending与取消行
在已保存SDK响应核isPending、isCancelled和cancelReason。REST的isPending固定false，因为待处理不进历史；isCancelled=true代表取消行，不能把取消回执当成功成交。
原REST isCancelled=true只看取消、false只看fill，省略才两者都含。若原筛选只取fill，找不到取消正常；未见具体失败原因不要补猜为余额不足或已退款。
检查结果：订单所处层级与筛选范围一致，取消/成交/待处理没有混记。
4. 核执行时间范围和截断
SDK start/end过滤executedAt，Unix秒UTC且含边界；pending没有执行时间，与isPending:true组合不会有executed-time命中。原发单时间不能直接作执行时间。
REST since为执行Unix秒；first范围1–1000、skip范围0–5000，较长历史文档建议按since缩小范围。当前count只是该响应记录量，未给完整历史总量；一个满页或大skip不能证明查全。
检查结果：秒/毫秒与提交/执行时间已分开，页面截断/过滤造成的缺漏仍被标出。
5. 按真实历史schema读成交与金额
REST响应是含orders/count等字段的对象，SDK是数组；前者用orderAction、price、notionalInUsd/Units，后者用action、px、ntl/szi。SDK字符串字段未在此页逐个明确单位，不能直接套REST USDC定义。
REST OrderFill可有null价格/金额。profitPercent是本次PnL百分比、totalProfitPercent是仓位整体百分比；amountSentToTrader和fee字段是USDC。pair.from/to可能保留旧SPX，而别处显示US500，先核pair id避免认为是另一资产。
检查结果：schema、数值单位、null与旧pair名称清晰，未把百分比或notional当净返款。
6. 将API失败与空历史分开
对本人原错误回执，400核trader格式/chainId/分页范围；429核retry-after与x-ratelimit-*共享预算；502表示上游subgraph不可达/超时/拒绝查询。错误不是orders=[]，不存在回执时保留未知。
限流页给60次/10秒/IP，且/v1/pairs、trades、limits和GET orders共享；它是文档条件，不能据此自动重试到取全。留下原x-request-id、请求范围和错误，公开求助时隐藏无关账户资料。
检查结果：HTTP失败、过滤空结果和确实无记录三种结论有各自证据。
7. 用执行行与接收材料完成对账
对同一仓位按Open、Close/TP/SL/Liquidation/RemoveCollateral串联原执行行。已有全平closePercent100或清算amountSentToTrader0都可有合理语义；取消与已成交的其他订单不互相抹除。
最终只将可对上的执行交易/钱包USDC接收及余仓状态写入结果。Closing页的即时返还说明不是你这笔交易的活体验收；日志缺失、金额null或只有提交hash时，完成项写成待核层级。
检查结果：可追溯从提交到执行/取消再到实际净接收；尚未完成层级明确。
怎样确认完成
- 能解释原订单缺漏是pending、取消筛选、执行时间、分页、错误或缺接收证据。
- documentation：官方方法与原记录核对条件已读；未登录、调用账户接口、修改订单或验证本人收款。
常见错误与边界
- 不要把当前REST amountSentToTrader/百分比字段改成SDK px/szi字段，也不要当事件ABI参数。
- start/end执行时间和REST since不能无条件拿用户提交时间替代；分页未给总量不声称全历史。