Hey, the space that I have been hosting for almost 2 years isn’t setting up properly. What’s going on? I know many others have this issue and it’s either because Hugging Face’s infrastructure was having a problem or that they are hosting a cryptominer. In this case, it is none of the above, so I am not sure why this is happening.
It’s been about 4 days now and I have tried duplicating the space to no avail.
This now also happens to me.
Me too… my customers are very upset and I’m not sure how to fix it.
Hello, we’re receiving the same issue. Spaces was working fine for us yesterday (July 31) and as of August 1 it’s been spinning indefinitely, making it past the Building Stage but getting stuck on “Starting on T4”.
We’re hoping there’s a fix soon? We’re using this platform for a school project and the deadline for our presentation is next week.
me too… i stuck with T4 in building stage… tried factory restarts and even creating configuration errors and pauses but none of these worked.
using docker space.
Same here.
It seems maybe Gradio-related trouble.
This symptom seems to have been fixed.
I’m getting another error, though…
Looks like today is a bad day to build.
Container logs:
===== Application Startup at 1970-01-01 00:00:00 =====
Did you take any action to solve the issue?
I still have the problem, I also tried to replace the hardware with some factory restarts, but it just got stuck on building.
No, I didn’t do anything special, but it was fixed today.
The Gradio version had to be 4.38.1 or lower to work properly for some reason with a mysterious GUI error, but the other problems were gone.
It’s not uncommon for HF to be temporarily out of order, but maybe there’s more than one factor in this case.
Today, I started getting build errors even in spaces with a fixed Gradio version of 4.38.1.
It seems that Gradio’s Examples is doing something bad, so I commented out the Examples-related stuff and now it works for the time being.
I didn’t think it would affect past versions.
It is a puzzling malfunction.
Speaking of which.
I have some Zero GPU space and CPU space on the HF and the only time I encountered this series of problems was when I was messing with the GPU space.
I don’t know if this means a hardware glitch on HF, a problem between the spaces library and Gradio, or if it’s totally coincidental.
Additional Notes:
The behavior of the above phenomenon was largely understood.
When starting the demo, Gradio now tries to strictly scan and cache the contents of Examples, but if there is a Dropdown that changes dynamically due to a function, etc., the scan sometimes fails and the demo crashes with an error.
This is a common Gradio tease, but this time it does not care if cache_example=False, if fn or outputs are not specified, or if Gradio is a slightly older version, it still scans and crashes with an error.
The current workaround is to comment out Examples or downgrade it to a very simple element (such as Textbox or Number).
However, no matter what I think, this is not normal behavior, so I guess the right thing to do is to wait for it to be fixed.
I’m assuming it’s part of those things, since GIT has been extremely bad for the past few days, and hardware capacity errors have been frequent, and so on.
This is not a Gradio-only problem. I am using a Docker space.
@radames any ideas?
Hey @pierric, sorry for the ping but could you take a look at No Language Left Behind - a Hugging Face Space by winstxnhdw. It’s been down for more than half a month now.
Then it seems likely that the problem is due to some specification change (or associated mistake or trouble) in the virtual environment itself deep in the HF server.
The time of occurrence also coincides with the time when the serverless inference API was restricted by a major specification change (without any announcement), and it is likely that some kind of renovation is underway under the surface.
I heard that putting in a complaint on Discord gets a quicker response, but I don’t use Discord, so I’ll leave it to someone else.
Hey @winstxnhdw , the issue is that the space is using caddy as the reverse proxy. We don’t allow reverse proxies in Spaces which is causing the issue.
I would see about removing Caddy and serving the app directly from Granian
Very strange. The first ever Hugging Face tutorial I followed was from a Hugging Face moderator which used Nginx as a reverse proxy for FastAPI. If this was a recent change in the ToS, it would be helpful to notify the community beforehand…
@winstxnhdw would you have a link for this tutorial so we can look into it?
There are several tutorials by @radames
See: nginx.conf · radames/nginx-gradio-reverse-proxy at main
Anyways, I have removed Caddy and my space is still stuck on Building… https://huggingface.co/spaces/winstxnhdw/nllb-api
Thanks for the link - the Space needed to be unflagged manually, it should build correctly now.