Subject: bug#63634: nar 404 leads to hard ‘guix substitute’ crash

From: Ludovic Courtès <[email-masked]>
Date: Mon, 22 May 2023 17:16:53 +0200

Hi,

Ludovic Courtès <[email-masked]> skribis:

>     646:2 10 (process-substitution _ _ _ #:cache-urls _ #:acl _ # _ # …)
> In ice-9/boot-9.scm:
>   1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
>     463:7  8 (download-nar #<<narinfo> path: "/gnu/store/dg0rm1mp9q…> …)
> In ice-9/boot-9.scm:
>   1747:15  7 (with-exception-handler #<procedure 7f6df0fa71e0 at ic…> …)
>   1685:16  6 (raise-exception _ #:continuable? _)
>   1683:16  5 (raise-exception _ #:continuable? _)
>   1685:16  4 (raise-exception _ #:continuable? _)
>   1780:13  3 (_ #<&compound-exception components: (#<&error> #<&irri…>)
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1683:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
>   1. &http-get-error:
>       uri: #<<uri> scheme: https userinfo: #f host: "bordeaux.guix.gnu.org" port: #f path: "/nar/zstd/dg0rm1mp9qvjhvlwra5mc8dz5pfky4hj-guile-colorized-0.1" query: #f fragment: #f>
>       code: 404
>       reason: "Not Found"
>       headers: ((server . "nginx") (date . #<date nanosecond: 0 second: 39 minute: 59 hour: 21 day: 21 month: 5 year: 2023 zone-offset: 0>) (content-type text/plain (charset . "utf-8")) (content-length . 3) (connection keep-alive))
>   2. &message: "https://bordeaux.guix.gnu.org/nar/zstd/dg0rm1mp9qvjhvlwra5mc8dz5pfky4hj-guile-colorized-0.1: HTTP download failed: 404 (\"Not Found\")"
> substitution of /gnu/store/dg0rm1mp9qvjhvlwra5mc8dz5pfky4hj-guile-colorized-0.1 failed

[...]

> This might be related to 8bd4126917f59f4af9a4323c3d5699201862dca2.  The
> two ‘download-nar’ calls are guarded against ‘http-get-error?’ though.

That the exception went through despite the ‘network-error?’ guard is
fixed by 3f59fd6d114548480c719d4b8f8509bdf3e8dcca.

The reason was that the ‘&http-get-error’ condition was getting wrapped
in a ‘kind-and-args’ exception upon rethrow, as illustrated here:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (catch #t
		       (lambda () (raise-exception (condition (&message (message "boo")))))
		       (lambda args args))
$5 = (%exception #<&message message: "boo">)
scheme@(guile-user)> (with-exception-handler (lambda (e) e)
		       (lambda () (apply throw $5))
		       #:unwind? #t)
$6 = #<&compound-exception components: (#<&error> #<&irritants irritants: (#<&message message: "boo">)> #<&exception-with-kind-and-args kind: %exception args: (#<&message message: "boo">)>)>
scheme@(guile-user)> (message-condition? $6)
$7 = #f
--8<---------------cut here---------------end--------------->8---

Ludo’.