fix(daemon-client): timeout reset clears daemon.json and daemon.lock without proving ownership
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Start in src/daemon-client/daemon-client-timeout.ts at resetDaemonState around line 191. Read readRegisteredDaemonOwnership and the existing lock liveness proof to understand the cleanup fence. Done means timeout cleanup declines with a typed reason when ownership is not proven and does not unlink daemon.json or daemon.lock.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
The daemon-client timeout reset path in src/daemon-client/daemon-client-timeout.ts (resetDaemonState, around line 191) unlinks daemon.json and daemon.lock without proving that this client's daemon is the process those files describe. It is the client-side twin of #3087: a client giving up on a slow daemon deletes the metadata of a daemon that is alive and simply busy, or of a successor that took over meanwhile.
Direction
Route the cleanup through the same fence the daemon uses — readRegisteredDaemonOwnership for the info file, and the existing liveness proof for the lock — and decline with a typed reason instead of unlinking. Client cleanup is what makes an absent record normal for the daemon at exit, so this path must stay fail-closed rather than simply deleting less.
Refs #3087, #3102
- Ngôn ngữ chính
- TypeScript
- Star
- 4.9k
- Fork
- 328
- Merge trung bình
- 11 giờ 49 phút
- Pull request đã merge (30 ngày)
- 585
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
callstack/agent-device#3407 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
callstack/agent-device#3353 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Client stop paths treat EPERM as a confirmed exit and drop state for a live companionCó thể đã có người làm @thymikee đã nhận hôm nay. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
callstack/agent-device#3540 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement needs-triage
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
callstack/agent-device#3531 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của callstack/agent-device
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
better-auth/better-auth#11723 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: docs difficulty: easy documentation good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Worker-Erstellung bricht langsame Git-Worktree-Checkouts nach 20 Sekunden abCó thể đã có người làm @KajoVanBuyten đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
AgentSystemLabs/agent-office#367 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
pierrecomputer/pierre#1187 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: frontend bug
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
snapotter-hq/SnapOtter#2425 ·
Maintainer thường phản hồi trong vòng 1 ngày