HF Space Stopped Working After Pinning

[ayymen]

I had a space on HF that was working for a year before I pinned it today which apparently broke it (probably because it was rebuilt).
I then tried duplicating the original space mine was based on and got the same error.

It looks like an infrastructure problem but is there anything I can do?

[John6666]

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)
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)

What the error really is

Your Space log shows two errors:

1. Root cause (first failure):

   • TypeError: argument of type 'bool' is not iterable
   • It happens inside gradio_client/utils.py in get_type(), called during Gradio’s get_api_info() JSON-schema conversion. (Hugging Face)

2. Secondary symptom (after the server is already broken):

   • ValueError: When localhost is not accessible, a shareable link must be created. Please set share=True... (Hugging Face)
     This shows up because Gradio tries to “self-check” the running app. Since the API route is crashing, Gradio concludes it cannot reach localhost and throws that ValueError. It is not the real problem.

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)

Gradio issue #11722 documents the same failure mode and suggests a minimal patch: handle isinstance(schema, bool) before checking "const" in schema. (GitHub)

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)

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)

What to do:

1. Edit README.md frontmatter.

2. Change:

   • sdk_version: 4.37.1 → sdk_version: 5.23.1 (or newer if you prefer, but start with the known-good one reported in the thread). (Hugging Face)

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)
  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)
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)
Several Spaces have implemented similar runtime patches in app.py commits as a workaround. (Hugging Face)

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)

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)
• 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)
• 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)
• 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)

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)
2. In app.py, change demo.launch() to include server_name="0.0.0.0", server_port=7860. (Hugging Face)
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)
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)
• HF “duplicated Space fails” thread + “upgrade sdk_version” fix and build-layer explanation. (Hugging Face)
• HF Spaces configuration reference (sdk_version, pinned). (Hugging Face)

Summary

• Your commit triggered a rebuild. The rebuild pulled a dependency combo that hits a known Gradio JSON-schema bug. (Hugging Face)
• Fix it by upgrading sdk_version in README (start with 5.23.1). (Hugging Face)
• Make demo.launch() explicit for Spaces networking. (Hugging Face)
• If needed, apply the bool-schema monkeypatch or move to Docker for long-term stability. (GitHub)

[ayymen]

Thank you. Upgrading the SDK version worked.