Reboot / Execute / SetSettings commands report success to the client but are silently dropped

オープン
  • 何か問題がありますか？
#32 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust
領域
api, backend

調査の方向性

Start in crates/podd-core/src/lib.rs:105-113 and trace how the dispatcher handles SetSettingsCbor, Reboot, Update, and Execute. Compare those paths with the API handlers in crates/api/src/handlers.rs:190-212 and control.rs:256-263 to understand how callers receive success. Decide what status callers should receive until these commands are implemented, then verify the affected API behavior.

索引モデルが issue の本文から書いたものです。

説明

bug

The API happily accepts these and returns success — post_jobs returns 204 for Job::Reboot (crates/api/src/handlers.rs:210-212), post_execute returns {success:true, message:"queued …"} (handlers.rs:190-195 via control.rs:256-263), and post_device_status forwards settings to apply_device_settings. But the dispatcher only logs them: Command::SetSettingsCbor, Reboot, Update, Execute all hit the not yet implemented // TODO(live-cutover) warn arms in crates/podd-core/src/lib.rs:105-113 and go nowhere. So the web UI's reboot button and the generic execute escape hatch are no-ops that look like they worked. (Update overlaps #1; Reboot/Execute/SetSettings do not.) Consider returning a not-implemented status until these are wired, so callers aren't misled.

Filed from a repo-wide code audit (working tree at bcad746).

主要言語
Rust
スター
0
フォーク
0
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

GoogleBot42/podd のほかの issue

GoogleBot42/podd の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。