GNU bug report logs - #49132
guix substitute: backtrace when the network is disabled during substitution

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: 49132 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: bug#49132: guix substitute: backtrace when the network is disabled during substitution
Date: Thu, 8 Jun 2023 23:17:53 +0200

[Message part 1 (text/plain, inline)]

> 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.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.