Dry-run OS/MCU apply records the new version, hiding the still-pending update from check() and status

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#39 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
rust
Bereich
backend, embedded-iot, testing

Rechercherichtung

Lies crates/pod-updater/src/agent.rs, insbesondere apply() und check(), und untersuche anschließend die Dry-Run-Schreibvorgänge in install.rs sowie den Test os_and_mcu_apply_are_gated_dry_run. Verhindere die Versionsaufzeichnung im Dry-Run-Modus und aktualisiere den Test so, dass er prüft, ob ein Vorschau-Lauf das Update verfügbar lässt und weiterhin die alte Version als installiert gemeldet wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

agent.rs apply() (crates/pod-updater/src/agent.rs:273-297) calls layout.record_version(kind, &component.version) after the OS/MCU writer returns Ok — including under dry_run, where nothing was actually flashed (DryOsSlotWriter/DryMcuFlasher just log and return Ok, install.rs:170-233). check() then filters out any component whose installed_version equals the manifest version (agent.rs:167-170), so after a single dry-run 'apply' the OS/MCU update silently disappears from available and current_versions reports the new version as installed even though the device still runs the old firmware. An operator doing a dry-run preview would afterward see no pending update. record_version should be gated on !dry_run (the os_and_mcu_apply_are_gated_dry_run test currently asserts the wrong behaviour).

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

Vorherrschende Sprache
Rust
Sterne
0
Forks
0
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus GoogleBot42/podd

Alle Issues in GoogleBot42/podd

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.