Docker Space stuck in APP_STARTING with stale runtime SHA
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.
My current read
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:
- the app appears to answer HTTP 200
- Gunicorn is listening on
0.0.0.0:7860 - the Space still reports
APP_STARTING - the runtime SHA is older than the repository HEAD
- restart / factory reboot attempts apparently do not move the runtime SHA forward
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:
- adding
app_port - changing the bind address
- changing
EXPOSE - increasing
startup_duration_timeout - making another random dummy commit
- changing dependencies without a new error pointing there
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.
Same vs different
| 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:
Similar 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.
Why I do not think this is the usual Docker Space startup issue (click for more details) Why startup_duration_timeout is probably not the main lever (click for more details) Similar public reports I found (click for more details) Why contacting HF support seems reasonable (click for more details)
Bottom line
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.
Discussion in the ATmosphere