Show update log on update error

[mtlynch]

When the update fails, we give the user a pretty opaque error message:

Meanwhile, in the error logs, we have useful information:

ERROR: Failed building wheel for cryptography
Failed to build cryptography
ERROR: Could not build wheels for cryptography, which is required to install pyproject.toml-based projects

https://logs.tinypilotkvm.com/kRbcpZt0

We should show the user the end of the update log and give the user the opportunity to easily capture the full logs at this point, since we really want to prevent update failures.

[jotaen4tinypilot]

@mtlynch A few thoughts on how we could approach this. I’d appreciate your feedback, maybe we manage to settle on a direction. Otherwise, I’m also happy to think more about this.

• In the <update-dialog>, we have the full update log at our disposal when the error occurs, so it should be fairly easy to include the full text in the “Details” box (or only the tail of it). I think that would be worthwhile to do in any event.
• At some point, we abandoned the option for users to copy the entire log output the clipboard. I think the reasoning behind this is still valid. The update logs might be equally long, depending on the point at which the error occurs in the update process, so I’m not sure it makes sense to bring back a “copy error to clipboard” button in the error dialog. I think we should only do this if we make sure that the “Details” won’t exceed a certain length, like say 20 lines – so in case of the update error, only if we show the truncated text.
• The “canonical” way for users to share error logs would be via a shareable link. That’s how we do it in the <debug-dialog>, at least. Based on that, we could consider to…:
  • Resemble the functionality from the <debug-dialog> in the <error-dialog>. In contrast to the <debug-dialog>, however, it would only share the specific error, without all the other system logs. We could achieve that by placing a “Get Shareable URL” link above the “Details” box, that would transition the dialog to basically the same state as after sharing from the <debug-dialog>.
    
  • Offer a button that takes the user to the system log dialog (<debug-dialog>). From there, they could view and share the full system logs as usual, and they also would be in full control over whether to hide sensitive data in the shared log text. Note, that we could also extend the wording of the dialog message in this case, so that the user knows what to make out of that “Open System Logs” button.
    

For both “sharing” options, we could either offer these new buttons/functionality by default for all errors, or we make it “opt in”, so that only particular errors have these extra buttons.

We could also combine the approaches, e.g.:

• Show truncated update logs in “Details” box for update errors
• Always have “Copy Error to Clipboard” button in <error-dialog> (as the error messages should usually be short)
• Offer “Open System Logs” button at the bottom, to make further diagnosis easier

[mtlynch]

At some point, #960. I think the reasoning behind this is still valid.

Ah, right! I forgot about that. Yeah, that's still true. I don't want to invite users to dump huge pastes anywhere, so I think shareable URL is the better option.

Resemble the functionality from the in the . In contrast to the , however, it would only share the specific error, without all the other system logs. We could achieve that by placing a “Get Shareable URL” link above the “Details” box, that would transition the dialog to basically the same state as after sharing from the .

Yeah, I like this one. I think System Logs is a good idea, but if something went wrong, I don't want to send the user to another screen without context. I'd rather they feel like they have everything they need to share diagnostics here.

I don't think there's a need to add it to other error dialogs yet, but we can keep it in mind if we encounter others where we expect that there's error messages we want to make it easier for the user to share.

[jotaen4tinypilot]

Proposal

Based on our discussion above, I’d like to propose the following UI changes, which aim to make the “Get Shareable URL” feature from the logs dialog (<debug-dialog> reusable in the error dialog.

Screen.Recording.2023-03-20.at.11.35.40.mov

Discussion

The problem with our current UI is that it transitions the dialog into a separate state for showing the resulting URL. That state is a dead end, however (because you can’t go back to the previous state), and it also lacks all the original context in which the user requested the URL.

For the <debug-dialog>, that is not that big of a problem, because the user is able to re-open the logs dialog again via “System > Logs”. For the <error-dialog>, however, there is no way to go back to the original error message, e.g. to make a screenshot, or review the initial error message again.

One approach to solve this would be to offer a “Back” button, but that would not just be tricky to implement with our current internal control flows (which are loosely coupled via events), I also would find that a bit “inelegant”. To me, a better solution would be to fetch the “shareable URL” without transitioning the dialog to a separate state, and then display the URL in-place once it’s there. That way, the original context is retained, and the action is less intrusive. (Which seems appropriate, since the action is secondary.)

We also wouldn’t need to show the conditional reminder that “sensitive data was hidden”, since the respective toggle button is literally right next to the “Get Shareable URL” button. (You could say that the reason why we introduced that reminder hint was said loss of context.)

Task break-down

• Introduce new standalone component <share-logs-button>, that contains both the UI functionality and the communication with the logs server
• Replace existing “Get Shareable URL” button in <debug-dialog> with that new <share-logs-button>
• Add new <share-logs-button> to <error-dialog> component in a conditional way, and activate it for update errors

[mtlynch]

Cool, yeah I like that design a lot!

[jdeanwallace]

@jotaen4tinypilot - I think this issue is done and can be closed right?

[jotaen4tinypilot]

Yes, thanks for the nudge! (I accidentally wrote Resolves of #1307 instead of Resolves #1307 in the final PR 🤦 , so it didn’t close.)