Failing to launch after seemingly successful build, no errors in log

Binder
1

My repo previously launched and ran fine in myBinder. Recently I got a pip dependency conflict on build,

#23 16.14 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
#23 16.14 notebook 7.3.2 requires jupyterlab<4.4,>=4.3.4, but you have jupyterlab 4.4.2 which is incompatible.
#23 16.14 Successfully installed ipython-8.37.0 ipywidgets-8.1.7 jupyterlab-4.4.2 jupyterlab_widgets-3.0.15 narwhals-2.1.2 numpy-2.2.6 pandas-2.2.3 plotly-6.1.0 pyscipopt-5.5.0 tzdata-2025.2 widgetsnbextension-4.0.14

Now my binder seems to build ok, no errors in the log at least, but does not launch, just hangs.

Here is the URL I use to launch it

How to debug this?

1 Like
2

It’s not you. Things aren’t working right now.
UPDATE: the administrators are now aware and it is being worked on.

I had just posted in the Zulip channel about my builds failing, too.
I think it is related because yours is failing/hanging in the build log much like mine with this ‘naming to registry’ step and then not launching:

#29 writing image sha256:a288a31be481d5ad17b8bc0510b8b8ce14d969c60da25d5d97fe8729bbefa856 done
#29 naming to registry.gesis.mybinder.org/i-dcurrie-2de-2dorp-64c470:287ef71643d59ea5d96a553929fe62cbdea60668 done
#29 DONE 0.2s

(Although sometimes yours seems to hang at earlier step, too. Like this:

#23 [11/18] RUN if [ ! -d "/home/jovyan" ]; then         /usr/bin/install -o jovyan -g jovyan -d "/home/jovyan";     fi
#23 CACHED

Weird.)

In short, you cannot debug it yourself. You can use an earlier commit to get a good launch though and then copy in your new stuff using git clone or something like that. Obviously not ideal, but it is really your only option until the system is fixed.

I also added a note in the Zulip channel pointing to this post thread, too.

Repo: GitHub - dcurrie/e-ORP: Optimal Retirement Planner

I see from your requirements.txt you are pinning everything and specifying some things MyBinder infrastructure will handle.
And maybe that is because you use this elsewhere and or know that works and want it documented? Either way…
I’d suggest instead making a binder directory, see about that option here, and making a separate requirements.txt in there where you don’t set the versions for any packages. (The configuration file in a binder or .binder directory are preferentially recognized by the MyBinder system and used instead of anything in root, when all is working normally.) And don’t list ipykernel,ipython, and nbformat. And remove jupyterlab_widgets. Unless absolutely necessary to specify the versions, I’d also suggest removing notebook and jupyterlab. Assuming most of those other packages left are kept up to date, your whole repo will work with MyBinder for longer going forward if you keep it like that.
Disregard this idea though if you are using something in there that isn’t well maintained and do need to pin. I though would still suggest removing the infrastructure-handled items from inside your special, custom binder/requirements.txt file.

1 Like
3

Thanks for reporting this @dougie and thanks for bringing it to our attention on Zulip, @fomightez!

This should be fixed now. But you got caught in the crosshairs a tiny bit @dougie. I think if you make a new commit to your repo (can be an empty no-op commit) it should fix your URL to launch too.

1 Like
4

Thanks @yuvipanda

Unfortunately, first try:

#24 pushing layer ea432ca59fe6 53.5s done
#24 pushing layer 90a2bf02e851 53.5s done
#24 DONE 53.5s
Built image, launching...
Launching server...
Server requested
2025-08-16T18:31:59.635944Z [Normal] Successfully assigned hetzner-gesis/jupyter-dcurrie-e-orp-c198o2g9 to svhz-css-mybinder-01
Error in event stream: TypeError: Load failed

Second try launched, though!

1 Like
5

Great! It worked for me here on first try. Let us know if you continue to run into problems.

As we ramp up mybinder’s reliability, these kind of user notices are important so we can figure out where problems are and fix them. So thank you so much for reporting them here, @dougie! I also find it difficult to monitor the discourse but do keep a sharper eye on the zulip, so thanks for reporting this there @fomightez!

1 Like
6 
#25 [17/19] COPY --chown=1000:1000 src/ /home/jovyan/
#25 DONE 1.3s

#26 [18/19] COPY /python3-login /usr/local/bin/python3-login
#26 DONE 0.4s

#27 [19/19] COPY /repo2docker-entrypoint /usr/local/bin/repo2docker-entrypoint
#27 DONE 0.3s

#28 exporting to image
#28 exporting layers
#28 exporting layers 27.0s done
#28 writing image sha256:d79d8e986c0d1f9d7b0972d4954946027feef0e67276527b0f6462f03939e22b done
#28 naming to registry.2i2c.mybinder.org/i-dayakaran-2den540205-2d6-387d30:1e2c4f0b2180f01c1f2cf0418b4d2509f32bf5b1 0.0s done
#28 DONE 27.0s

I think I might be running into a similar issue. Everything was working fine until yesterday, but since then the build just hangs after the message mentioned above.

Here’s the link.

Apologies if this turns out to be irrelevant to this topic.

7

Repo involved: dayakaran/EN540205-6

That definitely looks to be the same stopping point. I doubt it is irrelevant.

Your commit from four days ago launches just fine. The two most recent do not and are stopping at the same point.

I updated the thread over on Zulip with the current details, and we’ll see what is said.

8

@shivay if you make a new commit to your repo, it should build again. I’ll look into why this is happening!

1 Like
9

It’s working now. Thanks!

1 Like
10

Hello. I am also experiencing this problem, and it’s not clear to me what the fix is here. I have 2 repositories with identical environment.yml files and identical source code. One repo is based in my own personal Github account. It builds and launches successfully in Binder. The other repo is a member of an organization within Github. When attempting to build that one in Binder, it appears successful but never launches. The log freezes at the following item:

#31 exporting to image
#31 exporting layers
#31 exporting layers 11.2s done
#31 writing image sha256:0cf1f41b2ca91741e33ebfea7449068c9c65db0f1b20bcebf011e3df17c7a88c 0.0s done
#31 naming to ``registry.2i2c.mybinder.org/i-ufs-2dcommunity-2dufs-2danalysis-6c750a:b8b9918d7593fa3d66841d3ac9a7ca1c8c2b8e59`` 0.1s done
#31 DONE 11.4s

Links to repos:

Successful build and launch branch main

Frozen build and no launch branch sfs-analysis

Could the 2nd build be tripped up by a permission issue within the organization? I can’t think of any other possible differences between the repositories. Thank you in advance.

11

Yes, it seems the problem about naming to registry had popped back up. So when that happens is beyond your control and they have to work it out.
So you can only use old commits for launches when encountering until it is fixed.

UPDATE: You may want to try again as some steps have now been taken to address this.

Just to clarify a bit of what is going about the two repositories you reference:

The first one was done two days ago and probably an image was built then. If you try to launch from it now, there is no reason to build because the image exists already and the launch will be successful. So no issue with that one.

On the other hand…

For the second one, this commit on the sfs-analysis branch you only pushed 36 minutes ago. A new push triggers a new build being needed if you indicate to use the latest, the default essentially. So since builds are getting stuck it won’t build and since there is no image to launch, it cannot launch.

Hope that makes it clearer in regards to what you are seeing.

12

This is happening again. See Launch get stuck in building phase after write to registry · Issue #3387 · jupyterhub/mybinder.org-deploy · GitHub.

1 Like