Skip to content

~120 failed bind attempts per tool call when the port range is full — deliberate #18

Description

@GLouv

Filing this as a decided no, so nobody spends an afternoon "fixing" it and quietly weakens the thing it looks like a bug in.

Measured 2026-09-07: with the full range occupied, one tool call from a starved chat produces about 6 full bind cascades — roughly 120 failed bind() calls, each creating a WebSocketServer that is immediately discarded. That is because sendToExtension retries 5 times, and every retry calls sikrePort(), which walks the whole range again.

Why it stays: that cascade is the mechanism. It is what lets a chat that lost the port race pick up a port the instant another chat frees one — mid-call, without a restart. Before v1.29 a starved chat was dead for its entire lifetime. Damping the retry to save the attempts would trade the fix for the cosmetics of the fix.

What it actually costs: nothing measurable. EADDRINUSE returns immediately, the objects are garbage collected, and it only happens when the range is full — which is now rare, because ports are taken on demand.

What would change this: a cheap way to ask "is any port free?" without attempting a bind on each. If you know one, say so here — the goal is to keep the retry and drop the noise, not to drop the retry.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    wontfixThis will not be worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions