Skip to content

fix(dev): clear "can't reach the API" message; start-api refuses a busy port (#118) - #125

Merged
amar-python merged 1 commit into
mainfrom
fix/118-api-unreachable
Oct 27, 2026
Merged

amar-python merged 1 commit into
mainfrom
fix/118-api-unreachable

Conversation

@amar-python

Copy link
Copy Markdown
Owner

Part of #118. It doesn't close it: the cause of the 27 Oct silent API stop still needs evidence from the dev machine (see below).

What changes

Part Change
Browser message A new callApi() in session.ts turns a network failure into "Can't reach the API at http://localhost:8000. Is it running?" instead of the browser's bare "Failed to fetch". Cancelled requests (AbortError) pass through unchanged. Sign-in, sign-out, change password and every apiFetch call use it.
start-api.ps1 Before starting, it checks port 8000. If something already listens there, it prints the PID, process name, start time and the taskkill line, then exits 1. On 27 Oct an API left over from 02:12 kept the port, and a new API printed "running" but never served a request.
Window titles start-api.ps1 and start-frontend.ps1 set their window titles to "API (port 8000)" and "Frontend (port 8080)", as the product owner asked on 27 Oct.
QUICKSTART.md Two troubleshooting rows for the new messages. The stale "alembic.ini not found … no Alembic in this repo" row is removed, because alembic.ini has existed since #84.

Checks

  • vitest: 134 passed (it was 131). The new tests cover: sign-in while the API is down; another call while it's down (the session is kept); a cancelled request isn't reported as the API being down.
  • Mutation checks:
    • removing the network-error mapping makes 2 tests fail;
    • mapping every error, including aborts, makes 1 test fail.
  • tsc exit 0; eslint clean on session.ts.
  • PowerShell: both scripts parse with 0 errors (pwsh Parser.ParseFile) and stay ASCII-only (BUG-021). The port check itself (Get-NetTCPConnection) is Windows-only, so it couldn't be run here. It needs the dev-machine check below.
  • make lint exit 0. No Python changed.

Still open on #118 (needs the dev machine)

  1. Port check: with the API running, start a second .\scripts\start-api.ps1. It should print "Port 8000 is already in use by PID …" and exit.
  2. Silent stop: the cause of the morning stop hasn't been identified. Possible lead: --reload reacting to OneDrive syncs.

Done when


Generated by Claude Code

…sy port (#118)

- callApi() in session.ts: a network failure becomes "Can't reach the
  API at <base>. Is it running?"; aborts pass through. Used by sign-in,
  sign-out, change password and every apiFetch call.
- start-api.ps1: if port 8000 is already listening, print the PID, its
  start time and the taskkill line, and exit 1 instead of starting a
  second API that never serves requests.
- Both start scripts title their windows (API / Frontend).
- QUICKSTART troubleshooting: two new rows; drop the stale
  "no Alembic in this repo" row (alembic.ini exists since #84).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YPoXzBSj89ZHgw7nfTmbB
@amar-python
amar-python merged commit 6e68cde into main Oct 27, 2026
3 checks passed
@amar-python
amar-python deleted the fix/118-api-unreachable branch October 27, 2026 10:36
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.

2 participants