Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#39 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
74/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
linux, node.js, typescript
领域
networking, testing-qa

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
1
派生
0
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

HarperFast/integration-testing 的其他 Issue

查看 HarperFast/integration-testing 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。