Flowise Space Stuck on Building

[scooter7]

Hi,

Flowise Demo - a Hugging Face Space by scooter7 was running perfectly for two months. Yesterday, it stopped working, so I restarted the space. It is running on a paid server and has persistent memory. I have tried restarting several times, and it is stuck on building and has been now for over 12 hours. Any ideas how this can be fixed?

Thanks!

[John6666]

Was it about a week ago? I was experiencing a phenomenon where the space that had been working was becoming unbuildable due to errors, especially those related to Examples.
It seems that a similar phenomenon of another cause had occurred before that.
In my case, I was using Gradio, so I could barely work around it by simply commenting out the Examples-related errors, but I wonder how it would be with Docker…

Space is Building... permanently

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.

[scooter7]

This is a Docker space. It ran perfectly for two months. I have clients depending upon this space running, so I’m really hoping for a quick fix. I’ve never experienced issues with any of my other spaces, Gradio or Streamlit

[John6666]

Space is Building... permanently

This is not a Gradio-only problem. I am using a Docker space. @radames any ideas?

It was two weeks ago.
Somehow, I don’t think there is more than one cause of the build error, but at least at my time, it seemed that something higher up in the virtual machine, not Gradio, was scanning all the components of the demo just before launching the demo, executing the main functions and trying to get a sample output It seemed to be.
If there is a way to make it impossible to get samples, it might solve the problem in a non-Gradio environment if the cause is the same as mine.

If you are in a hurry, it may be faster to contact HF staff on Discord.
Or there, since they are just now soliciting feedback on the Post.

@victor on Hugging Face: "🙋 Calling all Hugging Face users! We want to hear...

[John6666]

It was fine until just now, but now I’m probably stuck with the same error.
It’s in the build forever.

FLUX LoRA the Explorer Mod - a Hugging Face Space by John6666

There was no sign of anything, and another private space (also a Zero GPU space) is in the same situation.
Restarts and factory rebuilds make no sense. It doesn’t seem to reach the contents of the user’s sources, and it doesn’t seem to make sense to change the sources either.

However, the other spaces that are not running builds are all running without any problems.

P.S.

I had to try to debug it because it was buggy.

• I created a new Zero GPU space and put the same source code there, and it built and worked fine.
• I changed the hardware of the space that was being built forever from Zero GPU space to CPU space and it worked.
• When I changed the hardware back, it went back to building forever again.
• If it’s a duplicate, it won’t be resolved during the build forever.
• If I delete the ZEROGPU_V2 environment variable, I’m out of the build forever, but I can’t delete this guy.
• super_squash_history has no effect.

Are we swamped per something like the hardware number assigned to each VM?
I dare wait as I can’t delete ZEROGPU_V2=true, but if you are in a hurry and you don’t need environment variables, it seems to be faster to create a new space and migrate.