Status.tsx: show as many different error types as possible (HMS-1442)

[schuellerf]

As far as I saw error.details rarely contains a .reason again.
It's sometimes directly a string and maybe there is error.details.s or it's even a list of strings
I'm really not sure if this is the right place to handle this but the error.details are somehow support to contain "arbitrary" stuff... (For this uncertainty it's a draft for now)

Also \n does not seem to work with react and <p> so I needed this map()

[schuellerf]

A total crash of osbuild should not happen but if it does it would look like this

NOTE: the forwarding of the last 20 lines of stderr is still to be committed if we want this - but it would look similar for other error details

[croissanne]

Amazing! thank you

[croissanne]

Huh what's the s field?

[schuellerf]

Update from our chats aside this issue:
It seems to stem from my confusion from the golang error type having the error in .s

https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/errors/errors.go#L67

but this seems to never land in the frontend anyway due to
https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/builtin/builtin.go#L309

not being able to serialize …
I'll remove from the frontend...

[croissanne]

Not sure about using code blocks here, the result doesn't work well for more common errors:

DNF:

target errors:

We can maybe make the popover wider, and then have reason and details just separated by a vertical line or something? Maybe just details in a codeblock?

If we can somehow tell when it's a stacktrace, putting that in a codeblock could be nice.

[schuellerf]

totally agree - that's actually for someone else to decide - I'm far away from being a react, PatternFly or design expert!

[kelseamann]

Hey, I like that we have the english error terminology separated from the code itself. I think it looks great!

[schuellerf]

@lucasgarfield what are your suggestions for visual improvements?
content wise this should be a little better than before

[regexowl]

Awesome! Thanks for looking into this!

Checked out how the error is formatted - would it make sense to extract the reason outside of the code block? If I understand it correctly the reason would be a shorter summary and the possible json/code snippets would be contained in the details.

Would something like this work?

      <Popover
        data-testid="errorstatus-popover"
        position="bottom"
        minWidth="40rem"
        bodyContent={
          <>
            <Alert variant="danger" title={text} isInline isPlain />
            <Text className="pf-u-pt-md pf-u-pb-md">{reason}</Text>
            <Panel isScrollable>
              <PanelMain maxHeight="25rem">
                <CodeBlock>
                  <CodeBlockCode>{detailsArray.join('\n')}</CodeBlockCode>
                </CodeBlock>
              </PanelMain>
            </Panel>
            <Button
              variant="link"
              onClick={() =>
                navigator.clipboard.writeText(
                  reason + '\n\n' + detailsArray.join('\n')
                )
              }
              className="pf-u-pl-0 pf-u-mt-md"
            >
              Copy error text to clipboard <CopyIcon />
            </Button>
          </>
        }
      >

(I've set a wider minWidth and moved the things around a bit so only the code part would be scrollable)

[regexowl]

/retest

[regexowl]

/retest

[regexowl]

/retest

[regexowl]

Looks great, thank you!