Gradio web components failing to load

Hmm… this could still be a transient glitch, but I wonder if the repository name itself may be part of the trigger:

This looks less like a problem inside the Space app itself and more like a failure in the Gradio web component’s Space lookup/status path.

The main clue is that the failing request is:

https://huggingface.co/api/spaces/by-subdomain/<space-subdomain>

and the error is:

{"error":"Invalid repo name: name/of_app - repo name includes an url-encoded slash"}

So, as a quick workaround / diagnostic, I would try the explicit Space repo-id form instead of the .hf.space URL form:

<gradio-app space="<owner>/<space_name>"></gradio-app>

instead of:

<gradio-app src="https://<space-subdomain>.hf.space"></gradio-app>

If space="<owner>/<space_name>" works while src="https://<space-subdomain>.hf.space" fails, that would strongly suggest that the app itself is fine and the failure is specifically in the .hf.space subdomain → Space repo lookup path.

A very similar issue is here:

• gradio-app/gradio#12570 — 404 Bad Request using Hugging Face Spaces API

In that issue, the failing request is:

GET https://huggingface.co/api/spaces/by-subdomain/jglowa-ai-gov-pl

and the response is:

{"error":"Invalid repo name: jglowa/ai-gov.pl - repo name includes an url-encoded slash"}

That looks very close to the error pattern here.

Why the repository name may matter (click for more details) Why space= is a useful test (click for more details) Suggested tests (click for more details) Related background issues (click for more details) Useful report format (click for more details)

Short version: this may still be a transient platform-side issue, but the specific console error points to the Gradio web component’s by-subdomain metadata/status lookup. Testing space="<owner>/<space_name>" instead of src="https://<space-subdomain>.hf.space" should help separate an app/runtime problem from a subdomain lookup problem.