{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidu6teagqkkcygkv62eqtzdmu45ucqhoqx77nkwy6mkdb5gzu5ugi",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mopnipsh4732"
  },
  "path": "/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992#post_2",
  "publishedAt": "2026-06-20T09:58:09.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "(click for more details)"
  ],
  "textContent": "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.\n\n* * *\n\n## My current read\n\nThis does **not** look like a normal Docker Space startup problem anymore.\n\nFrom the evidence already posted, the suspicious part is not simply “the app does not start.” The unusual part is the combination of:\n\n  * the app appears to answer HTTP 200\n  * Gunicorn is listening on `0.0.0.0:7860`\n  * the Space still reports `APP_STARTING`\n  * the runtime SHA is older than the repository HEAD\n  * restart / factory reboot attempts apparently do not move the runtime SHA forward\n\n\n\nThat combination makes this look less like a user-code issue and more like a stale Spaces runtime/control-plane state.\n\nIn other words, I would not mainly focus on the usual fixes such as:\n\n  * adding `app_port`\n  * changing the bind address\n  * changing `EXPOSE`\n  * increasing `startup_duration_timeout`\n  * making another random dummy commit\n  * changing dependencies without a new error pointing there\n\n\n\nThose checks are normally important, but they seem mostly ruled out by the current evidence.\n\nThe thing I would ask HF to inspect is something like:\n\n> 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.\n\n## Same vs different\n\nCompared with previous “Space stuck” reports | This case\n---|---\n**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`.\n**Same:** Some reports show stale runtime/build state after pushes, restarts, or factory rebuilds. | The runtime SHA remains older than the current repo HEAD.\n**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.\n**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.\n**Different:** Some cases recover after waiting or another rebuild. | Here, restart/factory reboot apparently did not advance the runtime SHA.\n\nSo my short summary would be:\n\n> 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.\n\nWhy 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)\n\n## Bottom line\n\nI would treat this as:\n\n> likely not a normal Docker Space startup failure, but a possible stale Spaces runtime/control-plane state.\n\nSince 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.",
  "title": "Docker Space stuck in APP_STARTING with stale runtime SHA"
}