Skip to content

Frontend shows 'Failed to fetch' when the API is down; the local API stopped silently once #118

Closed

Description

@amar-python

Found on 27 Oct while working through #116 on the dev machine.

What happened

  • The API stopped and nothing said so. The API had answered the wizard's health check, then its process (uvicorn --reload, started in its own window) stopped without a visible error. The cause is unknown. A possibility to check: the --reload file watcher reacting to OneDrive syncing files in the repo folder.
  • The message was no help. On the next sign-in attempt, the sign-in page showed only "Failed to fetch", the browser's raw network error. Nothing pointed to the API being down.

Proposed

  1. Frontend: when the API can't be reached, show "Can't reach the API at <VITE_API_BASE>. Is it running?" instead of the raw error. Do this in signIn() and apiFetch(), with a vitest test.
  2. Dev setup:
    • Find out why the API stopped: reproduce with --reload, inside the OneDrive folder.
    • If OneDrive turns out to be the cause, either drop --reload from scripts/start-api.ps1 or restrict it with --reload-dir api, and note it in QUICKSTART.

Done when

The friendly message is shown, with a test; and the cause of the stop is identified with evidence, or ruled out.


Generated by Claude Code

Activity

  1. added this to the Frontend and UI milestone on Oct 26, 2026
  2. amar-python commented on Oct 27, 2026

    @amar-python
    OwnerAuthor

    A second dev-machine finding on 27 Oct, 18:16 AEDT. It's related to the silent API stop above.

    What happened

    • The product owner started a new API at 18:09 with .\scripts\start-api.ps1. It printed "Uvicorn running on http://127.0.0.1:8000" and "Application startup complete", but it never logged a request.
    • Get-NetTCPConnection -LocalPort 8000 -State Listen showed only PID 11404, started 02:12:53. That was the API from the morning session, still running in the background with no visible window.
    • So every browser request went to the old process. Nothing showed that a second API had failed to take the port.
    • taskkill /PID 11404 /T /F stopped it (and child 23388). After a restart, the only listener was the new API (PID 30056, 18:17:52).

    To consider with the existing proposal

    • start-api.ps1: check port 8000 before starting. If it's taken, stop with a message naming the PID and its start time, rather than starting a second API that never serves anything.
    • QUICKSTART.md: add the check above to Troubleshooting.

    The cause of this morning's silent stop is still unknown. This finding suggests that the API may not have stopped at all, but been left running somewhere hard to see.


    Generated by Claude Code

  3. added a commit that references this issue on Oct 27, 2026
  4. amar-python commented on Oct 27, 2026

    @amar-python
    OwnerAuthor

    PR #125 was merged on 27 Oct (6e68cde): the clear "Can't reach the API" message, start-api.ps1 refusing a busy port, and window titles.

    Still open here:

    1. A screenshot of the port check on the dev machine. With the API running, start a second .\scripts\start-api.ps1.
    2. The cause of the 27 Oct silent stop, identified or ruled out.

    Generated by Claude Code

  5. amar-python commented on Oct 27, 2026

    @amar-python
    OwnerAuthor

    Port-check evidence: the product owner ran this on the dev machine on 27 Oct 2026 at 19:51 AEDT, at main 14f07e4, with the API already running.

    PS C:\Users\User\OneDrive\Desktop\Migration using ai\PostgreDataMigrationAppWithCSVLoader> .\scripts\start-api.ps1
    API_KEY not set - every endpoint is unauthenticated (fine for local dev).
    Port 8000 is already in use by PID 30056 (python, started 27/10/2026 6:17:52 PM).
    Another API is probably still running. Close its window, or stop it with:
        taskkill /PID 30056 /T /F
    

    The second API was refused, and the running API's PID and start time were named. This part of #118 is done.

    Still open: the cause of the 27 Oct morning stop, identified or ruled out.


    Generated by Claude Code

  6. added a commit that references this issue on Oct 27, 2026
  7. amar-python commented on Oct 27, 2026

    @amar-python
    OwnerAuthor

    Reopened under the closure rule: no issue closes without clean evidence attached.

    PR #127 was merged on 27 Oct (4635328), with CI 3/3 on 228091e. The "Done when" still needs the API window line Will watch for changes in these directories: [...\api] after a restart on the dev machine.


    Generated by Claude Code

  8. amar-python commented on Oct 27, 2026

    @amar-python
    OwnerAuthor

    Evidence for closure. The product owner ran this on the dev machine on 27 Oct 2026 at 21:39 AEDT, at main 4635328 (PR #127 merged).

    PS> taskkill /PID 30056 /T /F
    SUCCESS: The process with PID 19724 (child process of PID 30056) has been terminated.
    SUCCESS: The process with PID 30056 (child process of PID 8264) has been terminated.
    PS> .\scripts\start-api.ps1
    API_KEY not set - every endpoint is unauthenticated (fine for local dev).
    API starting on http://localhost:8000  (docs: /docs)
    INFO:     Will watch for changes in these directories: ['C:\\Users\\User\\OneDrive\\Desktop\\Migration using ai\\PostgreDataMigrationAppWithCSVLoader\\api']
    INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
    INFO:     Started reloader process [1904] using WatchFiles
    INFO:     Started server process [29140]
    INFO:     Waiting for application startup.
    INFO:     Application startup complete.
    

    Summary of #118:


    Generated by Claude Code

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

    bugSomething isn't working

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions