Users who pass a busy or out-of-range --port to doberman dash get a dashboard link that never loads, followed by a raw uvicorn error or a traceback.
Problem
In src/doberman/cli/main.py, dash declares --port with no range check (line 2497). It also prints Dashboard: http://127.0.0.1:<port>/?token=… before uvicorn.run tries to bind the port (lines 2540 and 2544). If the port is busy, the user sees the URL and then uvicorn's bind error, with exit code 1. With --port 70000, the user sees the URL and then a full traceback that ends in OverflowError. This behavior dates back to the original dashboard skeleton, and issue #714 tracks it.
Impact
This is a small usability problem. It causes no security or data issue. dash is a preview command: 15 users ran it in the last 90 days. The cli_command event records no exit code or error, so I can't tell how often the port error happens. The workaround is to choose another port.
Solution
Add min=1, max=65535 to the --port option so that Typer rejects a bad value with exit code 2. Before the URL prints, bind a throwaway socket to (_DASH_HOST, port) and close it. If the bind fails, print error: port N is already in use, try --port <another> and exit 1. Do the check before the heartbeat thread starts. Add dash rows for the new exit codes to the table in docs/CLI.md. Add tests to tests/unit/test_dash_serve.py: hold a port open and assert the error line, no Dashboard: line, and that the monkeypatched uvicorn.run was never called. Add a second test that asserts --port 70000 exits 2. Add a changelog fragment.
Expected impact
I can't give a credible estimate. The telemetry records no failures, so there is no baseline failure rate. After the fix, every bad-port run should end with one clear error line and no dead link.
- Actionability:
immediately_actionable
- Inbox status:
ready
- Signals behind it: 1
Open the report in PostHog
Filed automatically from the PostHog Self-driving inbox. It mirrors the finding; the fix is a maintainer's call.
Users who pass a busy or out-of-range
--porttodoberman dashget a dashboard link that never loads, followed by a raw uvicorn error or a traceback.Problem
In
src/doberman/cli/main.py,dashdeclares--portwith no range check (line 2497). It also printsDashboard: http://127.0.0.1:<port>/?token=…beforeuvicorn.runtries to bind the port (lines 2540 and 2544). If the port is busy, the user sees the URL and then uvicorn's bind error, with exit code 1. With--port 70000, the user sees the URL and then a full traceback that ends inOverflowError. This behavior dates back to the original dashboard skeleton, and issue #714 tracks it.Impact
This is a small usability problem. It causes no security or data issue.
dashis a preview command: 15 users ran it in the last 90 days. Thecli_commandevent records no exit code or error, so I can't tell how often the port error happens. The workaround is to choose another port.Solution
Add
min=1, max=65535to the--portoption so that Typer rejects a bad value with exit code 2. Before the URL prints, bind a throwaway socket to(_DASH_HOST, port)and close it. If the bind fails, printerror: port N is already in use, try --port <another>and exit 1. Do the check before the heartbeat thread starts. Adddashrows for the new exit codes to the table indocs/CLI.md. Add tests totests/unit/test_dash_serve.py: hold a port open and assert the error line, noDashboard:line, and that the monkeypatcheduvicorn.runwas never called. Add a second test that asserts--port 70000exits 2. Add a changelog fragment.Expected impact
I can't give a credible estimate. The telemetry records no failures, so there is no baseline failure rate. After the fix, every bad-port run should end with one clear error line and no dead link.
immediately_actionablereadyOpen the report in PostHog
Filed automatically from the PostHog Self-driving inbox. It mirrors the finding; the fix is a maintainer's call.