Distinguish monotonic clock failures from expired async deadlines
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 32/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ệ
- rust
- Lĩnh vực
- networking
Hướng nghiên cứu
Begin with std/task/net.wave around line 22 and trace the _remaining() helper through initial deadline creation, later async waits, and I/O. Discuss the result/error contract with @LunaStev before implementation, since the issue explicitly requires design agreement. Done means controlled clock failures retain their native identity and partial I/O counts, while expiration, infinite waits, and normal deadlines remain distinguishable and behaviorally unchanged.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Motivation
_remaining() returns zero both when the deadline has expired and when _now() reports failure. A verbatim-helper controlled-clock fixture returns remaining=0 for a clock error. Initial deadline creation instead reports invalid arguments; both paths erase the clock failure.
Starting point: std/task/net.wave:22.
Validation
Audited canonical Wave 540728c2eb6cc12f5c69c3fb3fdb96e07ba059a4 (0.0.1-alpha-dev), whose tree matches the local checkout. Validation: Executed verbatim _remaining helper with a controlled failing clock; no OS clock fault claimed. Executed compiler probes use the matching checkout-built compiler and std on Linux amd64 (Rust 1.89.0 / LLVM 21.1.8). Source/header or mocked checks are not native execution on another OS.
Scope
Choose a small result/error contract that preserves clock failures through async waits and I/O, instead of converting them into a timeout or invalid input. This is separate from the numeric timeout errno mapping.
Design discussion required
This issue records a proposal or an unresolved contract; it is not approval to choose new semantics. Please mention @LunaStev to discuss the design before starting implementation.
Completion criteria
- Controlled initial and later clock failures are distinguishable from actual expiration.
- Partial I/O counts and the native failure identity are preserved as agreed.
- Infinite waits and normal deadlines keep their current behavior.
- Ngôn ngữ chính
- Rust
- Star
- 56
- Fork
- 21
- Merge trung bình
- 23 giờ 20 phút
- Pull request đã merge (30 ngày)
- 45
Chuẩn bị môi trường
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 wavefnd/Wave
-
Reject unrepresentable POSIX listener descriptors before Unix-domain acceptCó thể đã có người làm @ShahadatTest đã nhận 6 ngày trước. Đang mởbug good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
wavefnd/Wave#1082 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Preserve expression assembly result types when recording HIR conversionsCó thể đã có người làm @hiyouwhatsapp đã nhận 2 ngày trước. Đang mởbug help wanted
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug help wanted
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 53/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Preserve the previous build output when writing its Cargo receipt failsCó thể đã có người làm @hiyouwhatsapp đã nhận 2 ngày trước. Đang mởbug build help wanted
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Reconcile obsolete staging assets before verifying a new Nightly generationCó thể đã có người làm @hiyouwhatsapp đã nhận 2 ngày trước. Đang mởbug ci help wanted
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug priority: medium
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
storytold/photocraft#12706 · 1 bình luận ·
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
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 85/100
IngvarConsulting/unica#2822 ·
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
-
Clean master build fails in zune-jpeg error conversion and zero-IV array construction (patch)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100