App canary health-check runs before the new release is activated, so it validates the OLD running podd

Đang mở
#38 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
backend, devops

Hướng nghiên cứu

Read crates/pod-updater/src/release.rs around install_app alongside crates/pod-updater/src/install.rs for staging and health checks, then inspect agent.rs rollback handling and the existing failing_health_check test. Trace when the new release starts and which release the health check observes; done means a failed new release is detected and rolled back automatically, with tests covering the real release flow.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

In install_app (crates/pod-updater/src/release.rs:117-133) the order is: stage() -> health.healthy() -> flip previous -> flip current -> installer.restart(). But stage() (SystemInstaller, install.rs:62) only mounts the squashfs read-only; it never launches the new podd. HttpHealthCheck (install.rs:118-140) polls http://127.0.0.1:3000/api/serverStatus, which is served by the still-running OLD release, because restart() doesn't happen until after the current flip. So the canary always reflects the old release's health: a new app build that crashes on boot still passes the canary, current gets flipped, and the service restarts into the broken release. There is also no post-restart verification and rollback() is never called automatically (only exposed as a manual method, agent.rs:318), so the advertised 'canary + instant rollback' safety net (lib.rs:22-24) does not actually protect against a bad app release. The failing_health_check test only passes because FnHealthCheck is decoupled from the real service.


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

Ngôn ngữ chính
Rust
Star
0
Fork
0
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của GoogleBot42/podd

Tất cả issue của GoogleBot42/podd

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.