Space: [Ama Backend - a Hugging Face Space by anandkr](https://huggingface.co/spaces/anandkr/ama-backend)
Hardware: CPU basic (free tier, 2 vCPU / 16GB RAM)
My Space has been stuck showing “Restarting” for over 16 hours. The UI tooltip says “This Space is restarting on commit 8240352. You can still use the previous version while it restarts.” — but 8240352
is a commit from several hours before my most recent pushes, and the Space has never progressed past this message despite multiple newer commits building successfully.
Timeline / what I’ve tried:
17f9b0b
(code change to server.py
, requirements.txt
, .dockerignore
). Build succeeded. Container logs showed a clean startup: Application Startup
→ model → Application startup complete
→ Uvicorn running on `` http://0.0.0.0:7860
. Dashboard still showed “Restarting.”ba4dd3b
(fixed a numpy
version issue from the previous build). Build log shows a fully successful pip install
and image push, no errors. Container logs again show a clean, healthy startup ending in Background load: resources ready.
. Dashboard still showed “Restarting,” with the same tooltip referencing the old 8240352
commit.c583b52
(prompt change only). Same result: build succeeds cleanly (full log available if useful), but the Space dashboard stays on “Restarting,” and the live endpoint (https://anandkr-ama-backend.hf.space
) keeps serving responses consistent with the old, pre-17f9b0b
code (verified by testing endpoint behavior that only exists in the new code, e.g. a 503 "warming up"
response right after restart vs. the old blocking behavior, and a prompt-wording change that’s absent from live responses).Summary: Every new build of this Space (3 in a row) completes successfully and the container itself starts up healthy per its own logs, but the Space never transitions to “Running” and traffic never cuts over to the new container. The two dedicated recovery actions (Factory rebuild, Restart this Space) had no observable effect either — Factory rebuild didn’t even appear to start a new build.
Dev Mode has never been enabled on this Space, so that’s ruled out as a cause (a common root cause for similar “stuck on old commit” reports on this forum).
This looks like a stuck deployment/cutover state on the platform side rather than anything in my Dockerfile or app code, since the same Dockerfile/app builds and boots cleanly every time. Has anyone seen this before, or is there a way to force a clean redeploy / get this Space un-stuck?