Space stuck "Restarting" on an old commit for 16+ hours — new builds succeed but never get traffic

A Hugging Face Space by user anandkr has been stuck in a 'Restarting' state for over 16 hours, failing to serve traffic from new builds despite successful container startups. The issue persists across multiple commits and is not resolved by factory rebuild or restart actions, indicating a platform-side deployment problem.

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 loading → 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?