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

On Linux, a listener on all interfaces makes loopback allocation wait forever, blaming a lingering Harper node

Đang mở
  • Có gì không ổn?
#39 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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
74/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ệ
linux, node.js, typescript
Lĩnh vực
networking, testing-qa

Hướng nghiên cứu

Start at getNextAvailableLoopbackAddress and trace how its canary bind failure leads to retries, then review the startHarper integration path and ForeignListenerError handling. Reproduce in a node:24-slim container with HARPER_INTEGRATION_TEST_LOOPBACK_POOL_COUNT=3 and a server on 0.0.0.0:9925; done means a covering listener raises ForeignListenerError instead of waiting indefinitely.

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

Mô tả

On Linux, a process listening on all interfaces on a canary port (9925 or 9926), such as a local Harper instance running with its default config, makes getNextAvailableLoopbackAddress wait forever. The conflict canary's exclusive bind fails with EADDRINUSE on every pool address, because Linux refuses a specific-address bind beside a wildcard listener. The pool reads that as a lingering node, skips the address, and retries all of them every second with no deadline, printing a warning that blames the wrong thing.

Reproduction

In a node:24-slim container, with HARPER_INTEGRATION_TEST_LOOPBACK_POOL_COUNT=3, a private TMPDIR, and a plain Node server on 0.0.0.0:9925, getNextAvailableLoopbackAddress() was still pending after 6 s, having printed each of these six times:

[loopback-pool] 127.0.0.2 is still in use by another Harper node (port 9925 bound); skipping to avoid an SO_REUSEPORT co-bind.
[loopback-pool] 127.0.0.3 is still in use by another Harper node (port 9925 bound); skipping to avoid an SO_REUSEPORT co-bind.
[loopback-pool] 127.0.0.4 is still in use by another Harper node (port 9925 bound); skipping to avoid an SO_REUSEPORT co-bind.

A suite then hangs in startHarper until the test runner's own timeout.

Relation to #38

#38 is the macOS side of the same condition. There the bind canary passes beside a wildcard listener, and the suite silently talks to the other process. Its fix connect-probes the canary ports once the bind succeeds and throws ForeignListenerError. On Linux the bind fails first, so that check never runs, and this wait is unchanged by it.

Possible fix

When the canary's bind fails, tell a covering listener apart from a node on the address itself: try the same exclusive bind on a loopback address that no pool node uses. Linux routes all of 127.0.0.0/8 to lo, so, for example, 127.255.255.254 is bindable without aliases. If that bind conflicts too, a listener covers every address, and the pool can throw the same ForeignListenerError as on macOS instead of waiting.

Ngôn ngữ chính
TypeScript
Star
1
Fork
0
Không có pull request nào được merge trong 30 ngày

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 HarperFast/integration-testing

Tất cả issue của HarperFast/integration-testing

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.