【要約】GMOコインFX APIの決済前キャンセル — 公式ERR-423と実測で見えたずれ [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動売買の運用者が、決済設計における公式ドキュメントと実挙動の乖離に直面した。設計の根拠としていたエラーコードの挙動が、実際のAPIレスポンスと一致しないことが判明したためである。具体的には以下の課題がある。
- ・公式のERR-423（有効注文による枠超過）を根拠に決済前キャンセルを設計したが、実測ではエラーが出ずに決済が通るケースがあった。
- ・数量超過時のエラーコードが、想定したERR-423ではなくERR-189として返る挙動を確認した。
- ・参照系GETにおいて、注文取消が即座に反映されない、あるいは同一スナップショットが再利用される問題があった。
// Approach
開発者は、実測に基づき設計根拠を再定義した。非同期な反映を考慮したポーリング処理も採用した。ドキュメントの解釈に依存せず、観測された事実に基づいた堅牢なフローを構築している。
- ・決済前に未約定注文を取り消す「cancel-first」の順序を維持した。
- ・取消後の反映待ちとして、orderedSizeが0になるまで最大4秒間のポーリングを実施した。
- ・APIの参照系GETがスナップショット単位で動作することを前提に、反映遅延を「世代間隔の上限」として捉える設計とした。
// Result
実測により、特定の条件下では有効注文が残っていても決済可能であることを突き止めた。これにより、エラー回避ではなく、より高次な目的のために決済シーケンスを維持する判断を下した。
- ・MARKET/満額/単一建玉の条件下では、有効注文があっても決済が成功することを確認した。
- ・ERR-189は、有効注文枠ではなく建玉数量の超過で発火することを特定した。
- ・参照系APIの世代間隔が約0.7〜1.7秒であることを観測した。
- ・「状態の単純化」と「レース回避」を理由に、cancel-firstと短ポーリングを継続する設計へ改善した。
Senior Engineer Insight
> 金融系APIの運用において、ドキュメントを絶対視せず、実測による「挙動の境界条件」の特定は不可欠である。本記事が示す「スナップショットの再利用」や「反映遅延の性質」への理解は、分散システムにおける整合性設計の勘所を突いている。エラー回避という消極的な理由ではなく、状態の単純化という積極的な理由で待機処理を組み込む設計思想は、システムの堅牢性を高める上で極めて実践的である。