Docker Space stuck in APP_STARTING with stale runtime SHA

A Docker Space on Hugging Face is stuck in APP_STARTING state with a stale runtime SHA, despite the app being reachable on port 7860. The issue persists after restarts and factory reboots, suggesting a stale runtime/control-plane record rather than a typical startup bug. Users are advised to contact Hugging Face support to inspect and reset the runtime state.

Hmm. There are many similar known Space errors, but this one feels slightly different from all of them. If you have not already done so, I think it may be better to contact Hugging Face support at website@huggingface.co too. This does not look like a normal Docker Space startup problem anymore. From the evidence already posted, the suspicious part is not simply “the app does not start.” The unusual part is the combination of: 0.0.0.0:7860 APP STARTING That combination makes this look less like a user-code issue and more like a stale Spaces runtime/control-plane state. In other words, I would not mainly focus on the usual fixes such as: app port EXPOSE startup duration timeout Those checks are normally important, but they seem mostly ruled out by the current evidence. The thing I would ask HF to inspect is something like: Could this Space have a stale runtime record, stale image metadata, or stale health/status registration? The repository HEAD is newer than the runtime SHA, while the container appears to be serving HTTP 200 on the expected Docker Space port. | Compared with previous “Space stuck” reports | This case | |---|---| Same: Docker Spaces can get stuck even when the app-side code is not obviously broken. | The app appears reachable and Gunicorn is listening on 0.0.0.0:7860 . | Same: Some reports show stale runtime/build state after pushes, restarts, or factory rebuilds. | The runtime SHA remains older than the current repo HEAD. | Different: Many older cases are ordinary port/bind/startup-timeout problems. | The usual app port , EXPOSE , bind-address, and basic health checks seem mostly ruled out here. | Different: Some stale-SHA cases are mainly BUILDING or queue-stall problems. | This looks more like APP STARTING / health-status registration staying stale while the app is reachable. | Different: Some cases recover after waiting or another rebuild. | Here, restart/factory reboot apparently did not advance the runtime SHA. | So my short summary would be: Why I do not think this is the usual Docker Space startup issueSimilar to previous stuck-Space reports, but not an exact match. The unusual part is reachable app + correct port + stale runtime SHA + failed restart/factory-reboot recovery. That smells like a stale Spaces runtime/control-plane record rather than a normal Docker/app startup bug. I would treat this as: likely not a normal Docker Space startup failure, but a possible stale Spaces runtime/control-plane state. Since the key evidence is already in the thread, I would not spend too much time changing app code unless a new log clearly points to an app-side crash. I would escalate it and ask HF to inspect/reset the runtime record, image metadata, or health/status registration for the Space.