# HTTP経由の戻り値と例外伝播

本ページは**ソースコード上の実装**を記述する。MG400実機で動作保証を確認したものではない。

## 自動ディスパッチ

標準サーバーは `api_spec=None` で `DobotCtrl` を登録する。`DeviceRouter._dispatch_handler()` は `method`、`args`、`kwargs` を受け取り、`adapter.unpack_args()` / `adapter.unpack_kwargs()` で引数を復元して公開メンバーを呼び出す。コルーチン関数は `await` するが、同期関数は非同期ハンドラー内から直接呼び出す。戻り値は `adapter.pack_result()` によりJSON応答に変換される。

明示的な `HTTPException` はそのまま送出され、それ以外の例外はログ記録後、`detail=str(e)` を持つHTTP 500に変換される。元のPython例外型がクライアントにそのまま復元されるわけではない。HTTP 200はディスパッチとシリアライズの成功を意味するにすぎず、ロボットの移動成功や物理I/O状態の確認を意味しない。

## クライアント

`SyncDeviceClient.dispatch()` と `AsyncDeviceClient.dispatch()` は `/instance/dobot/__dispatch__` にPOSTし、`adapter.unpack_result()` で結果を復元する。自動モードでは `__meta__` から戻り値型の記述情報を取得するが、戻り値の型注釈がないメソッドについて期待型が保証されるわけではない。

両クライアントの `_post()` は `raise_for_status()` を呼ぶ。HTTP 4xx/5xxはサーバー側のPython例外型ではなく `httpx.HTTPStatusError` として通知される。ネットワークエラーやHTTPタイムアウトはロボットの移動タイムアウトとは異なる。HTTPタイムアウトを、すでに受理された移動の停止・取り消しと解釈してはならない。

## 運用上の注意

- 通信失敗、HTTPディスパッチ失敗、コマンド受付、物理的な動作完了を区別する。
- タイムアウト後に移動指令を**無条件で再送しない**。先行指令が受理されている可能性があるため、先にロボット状態を照合する。
- Feedbackの鮮度やアラーム検出の制約は、HTTP経由でも解消されない。
- 本検証は静的なソース照合であり、HTTP結合試験とMG400実機試験は未実施である。

関連資料：[移動指令](motion_dispatch_audit.md)、[Feedbackとエラー](error_feedback_audit.md)、[I/Oと状態](io_state_error_audit.md)。