bug#37449: Bug when using non-trivial inferiors/channel setup

[Carl Dong]

Hi all,

This is a followup to some discussion between rekado, civodul, and I on IRC (see
end of email for transcript). There is a curious bug that happens when using
non-trivial inferiors/channels setup that triggers an error with vague output,
something like:

```
building path(s) `/gnu/store/myrl5p8fy3qhpdv7376sak8wmhdsrl5f-profile'
Backtrace:
           2 (primitive-load "/home/dongcarl/.config/guix/current/bi…")
In guix/ui.scm:
  1692:12  1 (run-guix-command _ . _)
   623:13  0 (_ srfi-34 #<inferior-object #<condition &store-protoco…>)

guix/ui.scm:623:13: Throw to key `wrong-type-arg' with args 
`("condition-has-type?" "Wrong type argument")'.
```

Both rekado and I have ran into this problem. Rekado ran into this problem when
using inferiors with more than one channel, and I ran into this problem when
using an inferior with a channel that has a .guix-channel file specifying a
'guix channel. A detail here is that it only triggers, but triggers reliably,
for certain packages in our manifests, with is quite odd.

I've attached the IRC conversation below for convenience.


Cheers,
Carl Dong
address@hidden
"I fight for the users"


```
<dongcarl> question about general Guix debugging... I'm building a manifest, 
and I see this: https://pastebin.com/JjpEjxaG
<rekado> dongcarl: I’ve bumped into this very same bug just a day ago
<dongcarl> It's hard to know where to look... :-/
<rekado> I’m not sure what’s going on here.
<dongcarl> rekado: REALLY?!
<rekado> a user at the institute, actually
<dongcarl> Where did you bump into it?
<dongcarl> Sounds like it needs to be fixed
<rekado> we’re using inferiors with more than one channel
<dongcarl> rekado: Right exactly!
<rekado> the user managed to avoid the problem for now by pinning the 'guix 
channel to commit 2f43e5db1c36ec93a80ed1e3cbe763a8d64adcb5.
<rekado> this sounds like a meta error, really
<dongcarl> Hmm... Well let me describe what I have
<rekado> there’s something triggering an error in an expression that is wrapped 
in “call-with-error-handling”
<dongcarl> Perhaps the info will be helpful for debugging
<rekado> but the error is not a condition, so the guard fails
<rekado> or something like that
<dongcarl> my manifest only has one channel in it, called `'bitcoin-guix`, and 
that channel's repo has a `.guix-channel` file that specifies a `'guix` channel
<rekado> actually, the error says that it got a “condition” but wrapped inside 
an “inferior-object”
<rekado> that’s the problem, I think
<rekado> it should just be a condition.
<rekado> the fact that we’re using an inferior results in a wrapped value
<rekado> it should be unwrapped before raising the condition.
<dongcarl> another piece of info, this is only happens for one of the packages 
in the manifest (I narrowed it down), all others are fine
— dongcarl reading
<rekado> same here
<rekado> it happened for python-scanpy
<rekado> others were ine
<rekado> *fine
<rekado> I’m guessing that this may be related to sexp->object in 
read-repl-response in guix/inferior.scm
<dongcarl> rekado: Huh...
<rekado> conditions don’t have a self-quoting sexp representation
<rekado> so they end up being wrapped in inferior-object
<dongcarl> rekado: Is this easy to fix?
<rekado> I don’t know.
<dongcarl> rekado: what should I look for in guix/inferior.scm? I can take a 
look
<rekado> read-repl-response expects to read either (values …) or (exception …) 
from the port
<rekado> I don’t know what a condition value would look like
<rekado> we probably need to a) make sure that conditions are serialized 
properly and b) handle them in read-repl-response.
<dongcarl> rekado: Why does this error only happen for _some_ objects and but 
not all?
<rekado> I don’t know
<rekado> we don’t even see the actual error.
<rekado> I guess (a) needs to be done in guix/repl.scm in send-repl-response
<rekado> the problem seems to be that there we only catch plain exceptions, but 
not conditions
— dongcarl needs to read up on exceptions and conditions
<rekado> (error 'foo) is an exception
<rekado> conditions are more complex and are defined in srfi-35
<rekado> conditions have proper types whereas plain errors really only have a 
key and optional arguments
<rekado> errors can be caught with (catch 'the-key …) or (catch #t …) for any 
error
<civodul> dongcarl: could you paste the error on, say, paste.debian.net? 
(patebin.com cannot be accessed over Tor)
<dongcarl> civodul: Yes, would love to, one second
<dongcarl> rekado: Ah the type distinction is good to know
<civodul> debugging exceptions from an inferior is... inconvenient
<dongcarl> civodul: http://paste.debian.net/hidden/03c69d6b/
<dongcarl> civodul: agreed
<dongcarl> I was actually thinking that perhaps inferiors can be a first-class 
`guix` cli construct... Not sure if that's possible
<dongcarl> As in, run the CLI as if `guix` was at this commit
<dongcarl> Maybe that's dumb :man-shrugging:
<dongcarl> gunna be back online in 30 mins if you guys need more logs or wtv
<civodul> dongcarl: oh, i see
<civodul> actually i don't see that much, mostly ellipses
<civodul> ah the re-throw for SRFI-34/35 is interesting
<civodul> it cannot work
<civodul> we should maybe serialize &store-error conditions over the wire
```