{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicioxlvjsianosv72f2skzu5lvfr2qmy6ug3gyog2fiy4tskdyvve",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mjnybga7rh22"
  },
  "path": "/t/spaces-build-does-not-use-latest-commit/175332#post_2",
  "publishedAt": "2026-04-17T01:42:11.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Hugging Face",
    "Hugging Face Forums"
  ],
  "textContent": "Oh… There **are several bugs** that could be causing the problem… not just one.\n\n* * *\n\nThere are real causes here, and they are mostly **not** “you forgot to force something.” Under normal behavior, a new commit to a Space repo should cause HF to rebuild the Docker image and provision a new VM for the new container. Separately, HF documents `factory_reboot=True` much more narrowly: it rebuilds from scratch **without caching requirements**. That means the official “hard rebuild” control is aimed at dependency-layer cache, not guaranteed recovery from a stale source snapshot or a stale runtime binding. (Hugging Face)\n\n## Bottom line\n\nThe symptom “build kicked off, but it did not use HEAD” usually falls into one of **three** real buckets:\n\n  1. **stale builder snapshot**\nThe build job itself is attached to an older commit than repo HEAD. This is the closest match to your complaint. Recent forum reports describe exactly that behavior: users pushed fresh commits, triggered redeploys, even did factory rebuilds, and the Space still picked an old version of the repo. (Hugging Face Forums)\n\n  2. **correct build, stale runtime**\nThe build may actually have used the right commit, but the running environment or served app is still bound to older state. A recent report showed the Space SHA moving forward while the runtime SHA stayed old, which is a strong signal that the control/runtime layer can lag behind the repo/build layer.\n\n  3. **platform-side queue/control trouble**\nSometimes the problem is broader than one repo. Empty logs, `Build queued` forever, or multiple Spaces acting strangely all point toward platform-side build/control issues rather than a bug in your repo.\n\n\n\n\n## The likely causes, in plain English\n\n### 1. HF selected the wrong source snapshot for the build\n\nThis is the most literal version of your problem. The repo HEAD is new, but the build job still starts from an older revision. The public reports from February 2025 are very close to this. In those cases, repeated commits and restarts did not reliably move the Space forward. (Hugging Face Forums)\n\n**How to recognize it:**\nCheck the **build log header** and compare its `Commit SHA` to your actual repo HEAD. If the log header itself is older than HEAD, you are not looking at a startup bug or a Gradio bug. The wrong source revision entered the build pipeline. (Hugging Face Forums)\n\n**Why factory rebuild may not fix it:**\nBecause the documented scope of factory rebuild is requirements-cache invalidation, not “guarantee that the source snapshot pointer is fresh.”\n\n### 2. The build used HEAD, but the runtime never really rolled forward\n\nThis is subtler, and it explains why users sometimes swear the build is wrong when the real problem is the running environment. HF’s config docs separate build success from **startup health**. A new image can exist, but if the app never becomes healthy enough, the platform can leave you with behavior that still looks like the previous version. The docs explicitly expose `startup_duration_timeout`, and they also document `preload_from_hub`, which exists precisely because startup-time downloads can make readiness fragile.\n\n**How to recognize it:**\nThe build log `Commit SHA` matches HEAD, but the app still looks old, or runtime metadata still points at an older SHA. That is the pattern shown in the “new Space SHA, old runtime SHA” report.\n\n**Typical hidden triggers:**\nSlow startup, model downloads at boot, startup health timing out, or runtime state not fully rotating to the new revision.\n\n### 3. The Space slug or deployment state is wedged\n\nThis is the broader control-plane explanation. A historical GitHub issue reported that restarting the Space did not update the served app, and the new app only appeared after a hardware switch. A separate 2025 report said the newest code only appeared after a different mode transition. Those are not “git fixes.” They are evidence that deeper infra state transitions can dislodge stale deployment state.\n\n**How to recognize it:**\nOne specific Space keeps acting wrong, while the same code in a fresh staging Space behaves correctly.\n\n### 4. A platform incident is making your repo look guilty\n\nThis is the case where build controls are unhealthy across the platform. The signal here is not one old SHA. The signal is empty or useless build logs, `Build queued` forever, or brand-new minimal Spaces also failing.\n\n**How to recognize it:**\nCreate a minimal test Space. If that also gets stuck or behaves strangely, stop blaming your repo first.\n\n## The solutions that actually make sense\n\n### Solution 1. Split “wrong build” from “wrong runtime” immediately\n\nDo this first:\n\n  * compare local `git rev-parse HEAD`\n  * compare the build log’s `Commit SHA`\n  * compare runtime behavior after startup\n\n\n\nThat one split tells you which class of fix is even relevant. If build-log SHA is old, you have a source/build selection bug. If build-log SHA is correct, you have a runtime/startup/control bug. (Hugging Face Forums)\n\n### Solution 2. Use one factory rebuild, once\n\nA factory rebuild is still worth doing **once** because it is the official full rebuild control. But treat it as a diagnostic control, not a cure-all. If the next build log still shows the wrong SHA, repeating factory rebuilds is unlikely to teach you anything new.\n\n### Solution 3. Create a fresh staging Space with the exact same latest commit\n\nThis is the best real-world diagnostic after the SHA check.\n\n  * **staging Space uses HEAD correctly** → your original Space state is likely wedged\n  * **staging Space also fails** → this is broader platform/account/build-path trouble\n\n\n\nThis is one of the cleanest tests because it keeps the code constant while changing the Space identity and deployment history. The public reports strongly support this style of diagnosis.\n\n### Solution 4. If the build SHA is correct, fix startup health instead of chasing git\n\nIf your build log matches HEAD, shift focus:\n\n  * reduce boot-time downloads\n  * use `preload_from_hub` for assets that must exist before the app is ready\n  * increase `startup_duration_timeout` if initialization is legitimately long\n  * inspect runtime logs, not build logs\n\n\n\nThis is the official config path for Spaces that “built fine” but never become cleanly ready.\n\n### Solution 5. If multiple Spaces or a minimal Space also fail, escalate fast\n\nAt that point, more commits are noise. Gather:\n\n  * Space URL\n  * expected repo HEAD SHA\n  * observed build-log `Commit SHA`\n  * timestamps\n  * whether a fresh minimal Space reproduces\n  * whether the issue is isolated to one Space or broader\n\n\n\nThat is the evidence package that distinguishes a real platform-side problem from repo-level debugging. (Hugging Face Forums)\n\n## What I would not do\n\nI would **not** keep pushing no-op commits hoping one lands. The 2025 reports show that repeated redeploys can fail to advance the Space. I would also **not** assume that “factory rebuild” means “invalidate every stale layer in the system,” because HF’s own API docs define it more narrowly than that. (Hugging Face Forums)\n\nI would also **not** jump straight to Dev Mode. You already ruled that out, and for this specific complaint the better path is to identify which layer is stale rather than change your workflow. The Dev Mode docs are still useful as a statement of what the normal non-Dev lifecycle is supposed to be. (Hugging Face)\n\n## My recommended order of operations\n\n  1. Check repo HEAD vs build-log `Commit SHA`. (Hugging Face Forums)\n  2. Run **one** factory rebuild.\n  3. If build-log SHA is still old, create a fresh staging Space with the same commit.\n  4. If build-log SHA is correct, treat it as startup/runtime and adjust readiness settings or preload strategy.\n  5. If a minimal Space also fails, escalate as platform-side.\n\n\n\n## My best short answer\n\n**Causes:** stale builder snapshot, stale runtime/control state, wedged Space state, or broader platform queue/control issues. (Hugging Face Forums)\n\n**Solutions:** compare SHAs first, use factory rebuild only once as a control, switch to a fresh staging Space if the original slug is wedged, tune startup if the build SHA is correct, and escalate quickly if a minimal Space also reproduces.\n\nThat is the shortest path that actually matches the evidence.",
  "title": "Spaces - build does NOT use latest commit"
}