Error Reporting: Basic and Complete

[rickmanelius]

What happened (or feature request):

• Feature request

What you expected to happen:

The DDEV UI connects with DDEV CLI through an API. To that end, debugging can be a challenge because it's not always apparent to the end-user where the source of the issue is coming from. To that end, DDEV UI needs to surface this information to the end-user in a variety of levels.

1. Top-level CLI issues. This would be related to things like Router Status Reporting Router Status Reporting #41
2. Top-level GUI issues. This might be something akin to not being able to reach the CLI, not having a proper version of the CLI to interact with, etc.
3. Terminal Output, Normal Mode: Show the normal terminal output that is coming through as ddev CLI is running commands.
4. Terminal Output, Verbose Mode: Essentially toggling on/off debug mode for DDEV CLI and reporting that output.

From a visual perspective, we need to do this in a way that doesn't overwhelm the interface, particularly items related to 3 and 4. Items related to 1 and 2 will probably take up less real estate and should be surfaced more prominently.

[rickmanelius]

Ideas:

• Hellobar approach where a user can click to pull up a tray that shows terminal output. If a general alert appears, the button glows red and when clicked it also highlights a global issue.
• Alternatively, terminal output is achievable through a hellobar like tray while global errors are reported in the footer with appropriate highlighting.

[rickmanelius]

Roadmap still needs updating. Until then I'm just going to tag as v0.2 because I feel this will be beneficial in debugging and testing.

[rickmanelius]

I feel like this may have been addressed in another area. To save me some digging, @andrew-c-tran is there another issue or PR or documentation that addresses this?

[rfay]

No, this was a completely different thing if I understand correctly. He demonstrated it at show-and-tell recently, but it hasn't made it into a PR.

[andrew-c-tran]

#54 can be integrated into this and this expanded out. This is a catchall complete logging issue, as #54 was intended to address how we're going to display the special case errors such as ddev cli being too old to use the UI and probably should be discussed here as well.

[andrew-c-tran]

An immediate need to proceed with this is how to display (wireframes/mocks) and organize event and warning states.

The following data is currently being collected (albeit in one big log)

• all DDEV CLI stdout output, grouped by processID
• all DDEV CLI stderr output, grouped by processID
• all JavaScript and Electron errors, ungrouped
• all promise rejections/internal errors (unwritable directory, cannot unpack, sudo rejected, etc), ungrouped
  *all of the above is timestamped and also arranged in a running log by time. grouped sets such as stdout and stderr from ddev cli are inserted at the time of the start of the process.

Possible error states include:

• Failure To Launch error state (ddev cli not installed, docker down, ddev cli version too low, etc)
• Global errors (JavaScript errors, docker or ddev cli crashes)
• Site specific errors (on card such as startup progress errors, unhealthy state errors)
• Process/modal errors (failure to unzip a file, unable to run hostname, etc)

Design decisions also needed on where/what to store in running logs. As demonstrated on demo day last month, all ddev cli stdout and stderr as well as internal JS and electron errors and warnings are being dumped to a big running log. Where should this log live? How should we separate them? How does the interface look and how is it accessed?

[andrew-c-tran]

Note: When displaying errors in the UI to the end user via error message modal, suggested format is to display just the message payload out of the msg portion of the error, and only the fatal error that caused the halt.

[dclear]

Basic is done; Dylan will spin up a new ticket for spec'ing out complete. Need verbose terminal output.

[dclear]

ticket created for complete reporting; closing this one.