> Ah indeed, this is poorly handled. > > I’m not really sure how to address it. I/O ports are a nice abstraction > as it allows you to transparently read “streams” from any medium, but as > always, that also comes with opacity where the call site is not supposed > to know what kind of exceptions might be thrown deep down. > > Thoughts? About 'as always, [...]’: [citation needed]. AFAICT, nowhere does Guile documentation state they they aren't supposed to know. Also, that seems a bad supposition to me if it prevents fixing the bug. I would just ignore that 'not supposed to’. I think this supposition needs some adjustment in order to be practical: guix/scripts/substitute.scm has opened the network connection (via http-client), so guix/scripts/substitute.scm is responsible for the connection (unless it delegates of course), so guix/scripts/substitute.scm is supposed to know what to do about exceptions involving that connection (unless it delegates). That there are some intermediate modules before things are actually read from the port is irrelevant -- substitute.scm opened the port, is responsible for the port and knows best how to handle exceptional situations involving that port. Nothing lower-level has the right context/information to make a good decision on how to handle the exception, so no delegation possible. As such, guix/scripts/substitute.scm should do it. It's not 100% clear from the backtrace, but it appears that the exception (from guix/scripts/substitute.scm perspective) happens at: ;; Procedure: process-substitution ;; Unpack the Nar at INPUT into DESTINATION. (define cpu-usage (with-cpu-usage-monitoring (restore-file hashed destination #:dump-file (if (and destination-in-store? deduplicate?) dump-file/deduplicate* dump-file)))) This should then be wrapped in an error handler catching 'bad-response', maybe reporting it, and switching over the next URL. Greetings, Maxime.