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

TypeScript: single-instance lock for the listening socket

Đang mở
  • Có gì không ổn?
#46 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

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
38/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, docker, node.js, typescript
Lĩnh vực
backend, build-system, operating-systems, testing

Hướng nghiên cứu

Read the existing Go and Rust lock implementations, then inspect the TypeScript listener and ts/Dockerfile. Run the skipped openListener concurrent test in ts/src/listen.test.ts and review spec/listener.qnt plus the TypeScript exception in spec/listener-design.md. Done means the locked configuration and TypeScript lock tests pass, concurrency leaves exactly one server, and reproducibility remains bit-for-bit.

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

Mô tả

Type: Enhancement

Is your feature request related to a problem?

#45 adds a single-instance lock to Go and Rust: flock(LOCK_EX|LOCK_NB) on <listen-socket>.lock, held for as long as the process runs. Node has no flock. On Node 22, fs.flock is undefined, there is no fcntl locking, and O_EXLOCK doesn't exist on Linux. So TypeScript relies only on the "in use" check (it connect(2)s to the existing socket before deleting it). That leaves a race between checking and deleting:

  1. A connects: refused, so the socket is stale.
  2. B connects: refused, so the socket is stale.
  3. A deletes the socket and binds. A is now live.
  4. B deletes A's live socket and binds. A keeps running, but nothing can reach it.

This only happens when two TypeScript instances start within a few milliseconds of each other on the same path. A second instance that starts after the first is listening is still refused. The race is recorded formally as raceWithoutLockTest in spec/listener.qnt, using the listener_unlocked module. It is a documented exception to the equal-peers rule; see spec/listener-design.md, section "TypeScript exception".

Describe the solution

A small in-repo N-API addon, about 30 lines of C, exposing flock(fd, LOCK_EX|LOCK_NB), with no npm dependency. TypeScript then uses the same lock as Go and Rust: the same file path, mode, O_NOFOLLOW and error messages.

This needs a change to ts/Dockerfile, which currently runs npm ci --ignore-scripts on stagex/pallet-nodejs. Either allow install scripts for that one package, or build the addon in an explicit step on stagex/pallet-nodejs or a StageX C-toolchain stage. make verify-reproducible-ts must stay bit-for-bit reproducible.

Done when:

  • the listener_locked Quint configuration covers TypeScript as well;
  • the skipped test openListener concurrent in ts/src/listen.test.ts is un-skipped and passes (8 instances started together, repeated 50 times, and exactly one ends up serving);
  • TypeScript passes the same lock unit tests as Go and Rust (symlink refused, unreadable lock file, released on SIGKILL).

Describe alternatives

  • An fs-ext-style npm addon: rejected. It's an external dependency built by install scripts.
  • Calling flock(1) from a shell: rejected. util-linux isn't in the runtime image.
  • An abstract-namespace lock socket: rejected. It's Linux-only and scoped to a network namespace, so two containers sharing a socket volume wouldn't see each other's lock.
  • A lock-free link(2)/rename(2) replace-and-check-inode protocol: rejected. It can still orphan a socket when three instances start together, and a live socket briefly disappears while it's being put back.

Which implementation(s) would this affect?

  • Go
  • Rust
  • TypeScript
  • Quint specification
  • All

Additional context

Follow-up to #45.

Ngôn ngữ chính
Rust
Star
2
Fork
0
Merge trung bình
14 giờ 26 phút
Pull request đã merge (30 ngày)
27

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 ChainSafe/docker-socket-policy

Tất cả issue của ChainSafe/docker-socket-policy

Issue tương tự

Thêm issue về Rust

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.