You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Frontend shows 'Failed to fetch' when the API is down; the local API stopped silently once #118
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
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.
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.
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.
Port-check evidence: the product owner ran this on the dev machine on 27 Oct 2026 at 19:51 AEDT, at main14f07e4, 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.
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.
Evidence for closure. The product owner ran this on the dev machine on 27 Oct 2026 at 21:39 AEDT, at main4635328 (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.
Cause of the 27 Oct silent stop: not reproduced. Its likely cause, the reloader watching the OneDrive-synced repo, is removed. Closed on that basis by the product owner's decision (option B). Reopen if the API stops by itself again.
Activity
amar-python commentedon Oct 27, 2026
A second dev-machine finding on 27 Oct, 18:16 AEDT. It's related to the silent API stop above.
What happened
.\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 Listenshowed only PID 11404, started 02:12:53. That was the API from the morning session, still running in the background with no visible window.taskkill /PID 11404 /T /Fstopped 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
Merge pull request #125 from amar-python/fix/118-api-unreachable
amar-python commentedon Oct 27, 2026
PR #125 was merged on 27 Oct (6e68cde): the clear "Can't reach the API" message,
start-api.ps1refusing a busy port, and window titles.Still open here:
.\scripts\start-api.ps1.Generated by Claude Code
amar-python commentedon Oct 27, 2026
Port-check evidence: the product owner ran this on the dev machine on 27 Oct 2026 at 19:51 AEDT, at
main14f07e4, with the API already running.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
Merge pull request #127 from amar-python/fix/118-reload-dir
amar-python commentedon Oct 27, 2026
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
amar-python commentedon Oct 27, 2026
Evidence for closure. The product owner ran this on the dev machine on 27 Oct 2026 at 21:39 AEDT, at
main4635328 (PR #127 merged).Summary of #118:
start-api.ps1refuses a busy port: PR fix(dev): clear "can't reach the API" message; start-api refuses a busy port (#118) #125. Run on the dev machine twice (19:51 and 21:38); each time it named PID 30056 and exited.api/only: PR fix(dev): reload the API only for changes under api/ (#118) #127. The line above shows it.Generated by Claude Code