Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

relay: the CLOSE-during-mint test synchronises on a 50 ms sleep and can fail under load

Đang mở
  • Có gì không ổn?
#963 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@chappie-daemon đang làm issue này rồi.

Từ ngày 25/10/2026.

  • #987 của @chappie-daemon — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
rust, typescript
Lĩnh vực
backend, testing

Hướng nghiên cứu

Start with crates/nostream-relay/tests/handlers.rs:1135 and inspect the test's CLOSE handling and gate release; then read testing.rs for the existing gate observables and Connection::read_in_flight. Replace the fixed 50 ms delay with a bounded wait for the abort signal or cleared in-flight read. Done when release is ordered after the abort, the timeout reports a clear failure, and the test no longer relies on sleep; pull request #987 is already open.

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

Mô tả

bug factory rewrite rust

a_close_during_the_invite_mint_leaves_the_event_but_not_the_read (crates/nostream-relay/tests/handlers.rs:1135, added in #962) synchronises the CLOSE against the invite mint with a fixed sleep:

gate.add_permits(1);

...is preceded only by tokio::time::sleep(Duration::from_millis(50)) after ["CLOSE","invite"] is sent. Nothing confirms the server has processed the CLOSE — i.e. that unsubscribe::handle has run abort_read and set the in-flight read's cancellation — before the gate releases the mint.

Failure mode: a false failure, not a false pass. If a busy runner delays the CLOSE handler past the sleep, the mint resumes first, the handler reaches fetch_and_send with the cancellation not yet set, and the test then observes the stored EVENT and the EOSE it asserts must not arrive. The fix is correct and the test goes red anyway. The window is small (50 ms against a local in-memory store) and the test passed in CI on #962, so this is a flake risk rather than a live defect.

Suggested fix. Wait for a server-side signal instead of for elapsed time. The crate already has the passive half — Connection::read_in_flight(id) is observable — so the options are:

  1. Poll fixture.connection(id).read_in_flight("invite") == false (the abort removes the entry) before gate.add_permits(1), with a bounded timeout that fails with a clear message rather than hanging.
  2. Add an observable for "a read was aborted" on the test double, mirroring the existing gate_reads / gate_reads_per_item / gate_creates idiom in testing.rs, and await it.

Either way the release becomes ordered after the abort by construction, and the 50 ms sleep goes.

Residual risk worth stating in the fix: the CLOSE's handler runs in a spawned task (relay.rs spawns each client message independently), so a wait on server-side state is the only ordering that does not depend on scheduling. That is also the mechanism behind #958, which is a separate pre-existing defect and not this test's problem.

Found by the Greptile review on #962 (P2). Recorded rather than fixed there, per the rule that a bot finding which is not a showstopper becomes its own issue instead of blocking the merge that revealed it.

Ngôn ngữ chính
TypeScript
Star
829
Fork
234
Merge trung bình
17 giờ 6 phút
Pull request đã merge (30 ngày)
92

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

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 cameri/nostream

Tất cả issue của cameri/nostream

Issue tương tự

Thêm issue về TypeScript

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.