# HF Space Stopped Working After Pinning
**URL:**
**Author:**  [@ayymen](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fayymen)%5C
**Post date:** [December 12, 2025, 8:10pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stopped-working-after-pinning%2F171484%2F1 "2025-12-12T20:10:04Z")
I had a [space](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner) on HF that was working for a year before I [pinned](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/commit/8d3efc0375ac258ceb2ab620c1dc251fb1293a51) it today which apparently broke it (probably because it was rebuilt).
I then tried duplicating the [original](https://huggingface.co/spaces/erastorgueva-nv/NeMo-Forced-Aligner) space mine was based on and got the same error.
It looks like an infrastructure problem but is there anything I can do?
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [December 12, 2025, 11:21pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stopped-working-after-pinning%2F171484%2F2 "2025-12-12T23:21:32Z")
Maybe compatibility issues due to library version upgrades.
* * *
This is fixable on your side. It is not “pinning” itself that broke the Space. The rebuild that happened after your README change pulled a newer (and now-incompatible) Gradio or Gradio dependency combination, and your app hits a known Gradio JSON Schema parsing bug.
## What changed when you “pinned”
Your commit only flipped the Space metadata flag `pinned` in the README frontmatter. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/commit/8d3efc0375ac258ceb2ab620c1dc251fb1293a51 "Update README.md · Tamazight-NLP/NeMo-Forced-Aligner at 8d3efc0"))
That alone is harmless, but any commit triggers a rebuild. On rebuild, the base image and dependency resolution can change even if your code did not.
HF explicitly documents `pinned` as “pin this Space to your profile,” and `sdk_version` as the thing that actually controls which Gradio version HF installs for Gradio Spaces. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference"))
## What the error really is
Your Space log shows two errors:
1. **Root cause** (first failure):
2. **Secondary symptom** (after the server is already broken):
## Why this is happening now
### The underlying bug
This is a known Gradio + gradio-client incompatibility: JSON Schema allows some fields (notably `additionalProperties`) to be a **boolean** (`true` or `false`). Gradio’s API info generation can produce such schemas, and `gradio_client.utils.get_type(schema)` assumes `schema` is a dict and does `if "const" in schema`, which crashes if `schema` is a bool. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
Gradio issue #11722 documents the same failure mode and suggests a minimal patch: handle `isinstance(schema, bool)` before checking `"const" in schema`. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
### Why duplication also fails
Duplicating a Space forces a fresh build in today’s HF environment. If the template Space relies on “whatever versions happen to be current,” you can reproduce the same crash even without changing app code. The “Agents course” thread shows exactly this: duplicating caused the same `bool is not iterable` crash until users upgraded the Gradio SDK version in README. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
## The highest-probability fix for your Space
### Fix 1 (recommended): Upgrade the Gradio SDK via README `sdk_version`
Multiple HF users fixed this exact crash by upgrading the Gradio SDK version set in README metadata (the thing HF uses to install Gradio). In that thread, setting it to `5.23.1` worked for many people. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
What to do:
1. Edit `README.md` frontmatter.
2. Change:
3. Commit.
4. In the Space settings, run a restart or factory rebuild if it does not auto-rebuild cleanly.
Why README matters more than `requirements.txt` here:
- HF’s own build process may install your `requirements.txt` first, then **install Gradio afterward** , overwriting any Gradio you tried to pin in requirements. A user in the same incident thread observed that HF runs a later layer like `pip install ... gradio[oauth]==...`, which overrides earlier installs. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
So control Gradio via README `sdk_version`, not `requirements.txt`.
### Fix 2 (strongly suggested): Make launch explicitly “Spaces-safe”
Your app ends with `demo.launch()` with no parameters. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/blob/main/app.py "app.py · Tamazight-NLP/NeMo-Forced-Aligner at main"))
Once the schema crash is gone, this often works, but it is still safer to be explicit on Spaces:
Use:
- `server_name="0.0.0.0"`
- `server_port=7860`
This avoids “localhost not accessible” style failures. In your current logs that ValueError is secondary, but making launch explicit reduces future fragility.
## If upgrading Gradio still doesn’t fix it
You have two practical fallback options.
### Fallback A: Pin a known-good `gradio_client` (or patch it)
Because the crash is in `gradio_client.utils.get_type()`, you can harden it.
Two approaches you will see in the wild:
- **Monkeypatch** `gradio_client.utils.get_type` to handle `bool` schemas.
- Patch more broadly to coerce boolean schemas into safe dict-like schemas.
The Gradio issue proposes the minimal defensive line `if isinstance(schema, bool): ...` as the core fix. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
Several Spaces have implemented similar runtime patches in `app.py` commits as a workaround. ([Hugging Face](https://huggingface.co/spaces/Sephfox/Cain/commit/f372e0ad2f396efa7b185cf84ca2f7fe91d0e09a "Sephfox/Cain at f372e0a - Update app.py"))
This is not “pretty,” but it is effective when you cannot control the exact transitive dependency set.
### Fallback B: Switch to a Docker Space for reproducibility
A Gradio Space rebuild can change base layers and transitive dependencies over time, even if your repo is unchanged. The clean way to freeze everything (OS libs, Python version, pip resolution, CUDA libs) is Docker Spaces. The HF incident thread explicitly points to HF’s Docker SDK docs when discussing how the build layers behave. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
## Similar cases online
These are genuinely the same class of failure, not generic “bool not iterable” Python advice:
- **Gradio bug report (core root cause + patch idea)**: Gradio `get_api_info()` crashes because schema contains boolean where dict is expected; suggests handling `isinstance(schema, bool)` in `gradio_client.utils.get_type`. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
- **HF Spaces incident thread (mass reproduction on duplicate + fix)**: “Can’t get the space to run” with the same stack trace; users report fixing by upgrading Gradio SDK in README (example: `5.23.1`). Also notes HF build layering can overwrite requirements-installed Gradio. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
- **HF Space discussion mirroring your error** : Another Space shows the same `TypeError` at launch and points to the “upgrade README SDK” fix thread. ([Hugging Face](https://huggingface.co/spaces/cavargas10/TRELLIS-Texto3D/discussions/1 "cavargas10/TRELLIS-Texto3D · TypeError: argument of type 'bool' is not iterable"))
- **HF forum post (same symptom class, dependency drift)**: “Internal server error / bool not iterable” discussion frames it as dependency conflicts and rebuild drift rather than user code. ([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Finternal-server-error-bool-not-iterable%2F149494 "Internal server error / bool not iterable - Beginners"))
## A concrete “do this now” sequence for your repo
1. In `README.md` frontmatter, bump `sdk_version` from `4.37.1` to `5.23.1`. Keep `pinned: true` if you want it pinned. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/commit/8d3efc0375ac258ceb2ab620c1dc251fb1293a51 "Update README.md · Tamazight-NLP/NeMo-Forced-Aligner at 8d3efc0"))
2. In `app.py`, change `demo.launch()` to include `server_name="0.0.0.0", server_port=7860`. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/blob/main/app.py "app.py · Tamazight-NLP/NeMo-Forced-Aligner at main"))
3. Rebuild. If it still fails with the same stack trace, add the minimal `gradio_client.utils.get_type` bool-guard monkeypatch as a temporary workaround, matching the Gradio issue’s fix idea. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
4. If you want “it will still run a year from now,” migrate to a Docker Space.
## Curated references worth keeping open
- Gradio bug: boolean schema crash + suggested patch. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
- HF “duplicated Space fails” thread + “upgrade sdk\_version” fix and build-layer explanation. ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
- HF Spaces configuration reference (`sdk_version`, `pinned`). ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference"))
## Summary
- Your commit triggered a rebuild. The rebuild pulled a dependency combo that hits a known Gradio JSON-schema bug. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner "Nemo Forced Aligner - a Hugging Face Space by Tamazight-NLP"))
- Fix it by upgrading `sdk_version` in README (start with `5.23.1`). ([Hugging Face](https://huggingface.co/spaces/agents-course/First_agent_template/discussions/251 "agents-course/First\_agent\_template · Can't get the space to run"))
- Make `demo.launch()` explicit for Spaces networking. ([Hugging Face](https://huggingface.co/spaces/Tamazight-NLP/NeMo-Forced-Aligner/blob/main/app.py "app.py · Tamazight-NLP/NeMo-Forced-Aligner at main"))
- If needed, apply the `bool`-schema monkeypatch or move to Docker for long-term stability. ([GitHub](https://github.com/gradio-app/gradio/issues/11722 "Internal error in Gradio when handling boolean schema in ..."))
---
**Author:**  [@ayymen](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fayymen)%5C
**Post date:** [December 13, 2025, 12:39am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stopped-working-after-pinning%2F171484%2F3 "2025-12-13T00:39:33Z")
Thank you. Upgrading the SDK version worked.
---
**Author:**  [@system](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fsystem)%5C
**Post date:** [December 13, 2025, 12:40pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stopped-working-after-pinning%2F171484%2F4 "2025-12-13T12:40:01Z")
Closed on December 13, 2025, 12:40pm UTC
This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.