@remotion/studio: Use server.listen() for port availability checks#6939
Merged
JonnyBurger merged 2 commits intomainfrom Mar 31, 2026
Merged
@remotion/studio: Use server.listen() for port availability checks#6939JonnyBurger merged 2 commits intomainfrom
@remotion/studio: Use server.listen() for port availability checks#6939JonnyBurger merged 2 commits intomainfrom
Conversation
Switch back to using `server.listen()` instead of `socket.connect()` to determine if a port is available. This directly tests whether a port is bindable, rather than inferring availability from a failed connection. The original implementation used `server.listen()`, but it was switched to `socket.connect()` in v3.0.13 (000d421) to fix a port selection issue (#1023). However, the `connect()`-based approach breaks on WSL2, where Windows' port forwarding proxy accepts TCP connections on 127.0.0.1 and 0.0.0.0 across a large port range (~1024–41000) even when nothing inside WSL is listening. This causes every port in the 3000–3100 scan range to appear occupied, and the studio fails to start with "No available ports found". Closes #4315 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
|
Reviewed PR #6939 — approved. The switch from Task list (4/4 completed)
|
Contributor
There was a problem hiding this comment.
Clean, well-motivated change. server.listen() is the correct primitive for testing port bindability — it avoids the WSL2 port-forwarding false positives inherent to socket.connect(). Error handling is solid, and server.unref() is a nice defensive touch.
Big Pickle (free) ｜ 𝕏
With server.listen(), binding a port on one host (e.g. ::) can claim it on all interfaces, causing parallel listen() attempts on other hosts to fail with EADDRINUSE. Test hosts sequentially so each server is closed before the next one tries to bind. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
server.listen() for port availability checks@remotion/studio: Use server.listen() for port availability checks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
socket.connect()toserver.listen()for port availability detectionHistory
The original implementation used
server.listen()to check port availability — the most direct way to test if a port is bindable.In v3.0.13 (
000d42195b), this was changed tosocket.connect()to fix a port selection issue (#1023). The renderer was synced to match in v3.0.18 (fe00816c25).However, the
connect()-based approach has a fundamental flaw on WSL2: Windows' port forwarding proxy accepts TCP connections on127.0.0.1and0.0.0.0across a large port range (~1024–41000), even when nothing inside WSL is actually listening. This makes every port in the 3000–3100 scan range appear "occupied", so the studio HTTP server never starts.server.listen()is the correct fix because it directly tests bindability rather than inferring availability from a failed connection attempt.Context
connect(): #1023 — this turned out to be a timeout handling bug in theconnect()-based code itself, not a problem with thelisten()approachTest plan
Closes #4315
🤖 Generated with Claude Code