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.