Space stuck in ‘Build Queued’

I have read most threads regarding the same situation “space stucked in build queued.”

Now all my spaces, included any new created spaces, will failed to build. And base on all the previous threads, this is very likely a huggingface issue and require hugging face’ team support.

Can any admin help me to resolve this issue?

-------------------------The ERROR at the build logs-----------------------------------------

→ COPY --link --chown=1000 ./ /home/user/app
DONE 0.0s

→ RUN pip freeze > /tmp/freeze.txt
DONE 1.0s

→ COPY --from=pipfreeze --link --chown=1000 /tmp/freeze.txt .
DONE 0.0s

→ Pushing image
→ COPY --link --chown=1000 --from=lfs /app /home/user/app
CACHED

→ Restoring cache

→ Pushing image

→ ERROR: failed to push private.docker-builder-registry-s3.internal.huggingface.tech/spaces/65bb3cbe2524c0c9843d12ac:cpu-ff1b92e: failed to copy: operation error S3: GetObject, https response error StatusCode: 404, RequestID: 0SRSN8THY1JDJ13E, HostID: yme3g5zRpSupbkPs9jXoOmb/5GgtJkIEa+UITbIP0vVfpmjJf4IuK7S5JsRYg0424ZjNjpQfC1c=, NoSuchKey:

1 Like

I am having the exact same issue, this is probably because of an internal huggingface update

Are you expecting them to recover after few hours?

Probably, as huggingface normally fixes these kind of issues pretty quickly. Might be an issue with AWS though.

I agree, lets wait

The problem is fixed for me, wbu?

Hi @keble @Araeynn, thanks for reporting. We’ve applied a patch and triggering a restart to your Space should do the trick. Let us know though if you continue to see an issue. Thanks again!

Hey, I’m facing the same problem with my spaces. I tried duplicating it, it wroks until I make any edit or restart it.

hi i am facing the same issue

I’ve been experiencing the same issue for a whole day. Even restarting the space doesn’t help.

Try this.

And/or mention or report to victor.

Hi, I meet the same issue now, and I try to restart space but it does not still work : keep building for about 6 hours; Could anyone know how to fix it ?

2 Likes

If you get a build error, it’s often because of a mistake on the user’s side, and it can often be resolved by making a few tweaks. However, if it just stops without a build log, it’s probably because HF is stopping the execution for some reason.

For example, if there is a Docker file that contains a library that has been implicitly banned because it has been misused, it will stop. This is particularly common with network-related libraries.
If you have something you got from github, this is probably the case.

Also, if you try to build a Spaces that contains a file larger than 1GB that you were able to upload in the past but can’t upload now, it will also stop. I forget whether a log is output or not. In this case, if you change the specification to place the large file in the model repo and download it when Spaces is started, it will be fine.

If it stops without a build log, how can we determine the reason for the ban? How can we identify which library is causing the issue?

1 Like

If it is made public, people who misuse it will use the public information, so it is probably not public.
For us, the only way is to eliminate the candidates one by one…
Well, in this case, it is probably caused by one of the network-related libraries, so I think it will be found relatively quickly if it is a build stack due to restrictions.

1 Like

I am using the Caddy server. This is probably what is causing the problem in my case.