Skip to content

fix: do not use fallback port in production#223

Merged
pi0 merged 1 commit into
mainfrom
fix/no-fallback-port-in-prod
Apr 30, 2026
Merged

fix: do not use fallback port in production#223
pi0 merged 1 commit into
mainfrom
fix/no-fallback-port-in-prod

Conversation

@kricsleo

@kricsleo kricsleo commented Apr 7, 2026

Copy link
Copy Markdown
Member

resolves #222

Summary by CodeRabbit

  • New Features
    • Production mode now enforces binding to the requested port; if it’s already in use, the server fails with a clear error instead of switching to another port.
    • Non-production mode retains automatic fallback to an available port within the usual range.
  • Tests
    • Added coverage to verify environment-specific behavior when the requested port is occupied, ensuring production errors and non-production falls back as expected.

@coderabbitai

coderabbitai Bot commented Apr 7, 2026

Copy link
Copy Markdown

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e26dfbd1-ab83-47bf-9d2b-24c9f7dfa199

📥 Commits

Reviewing files that changed from the base of the PR and between 60ba9f2 and 4936be6.

📒 Files selected for processing (2)
  • src/listen.ts
  • test/index.test.ts

📝 Walkthrough

Walkthrough

Port resolution behavior updated to enforce strict binding in production: when the specified port is unavailable in production mode, the system fails with an error instead of attempting an alternative port. Development mode retains the original fallback behavior.

Changes

Cohort / File(s) Summary
Port Resolution Logic
src/listen.ts
Modified getPort invocation to conditionally pass random: false when isProd is true, replacing the constant alternativePortRange: [3000, 3100] approach. Non-production mode preserves existing alternative port range behavior.
Production Port Error Handling Test
test/index.test.ts
Added test case verifying that listen() with isProd: true rejects with an error when the desired port is already occupied, rather than resolving to an alternative port.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 In production we plant our feet firm and true,
No dancing to random ports—that simply won't do!
If the port is taken, we fail with a cry,
While dev gets a backup when troubles draw nigh. 🎪
Strict mode for the servers, chaos kept at bay! 🚀

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'fix: do not use fallback port in production' accurately summarizes the main change: preventing fallback port binding in production mode.
Linked Issues check ✅ Passed The code changes directly address the requirement from issue #222: when isProd is true, the alternative port range is removed and random: false is set, causing hard failure when the desired port is unavailable.
Out of Scope Changes check ✅ Passed All changes are directly scoped to the objective of fixing fallback port behavior in production. No unrelated modifications were introduced.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/no-fallback-port-in-prod

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@pi0 pi0 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@pi0 pi0 merged commit 33c98f2 into main Apr 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Should not use random free port in production if main is busy

2 participants