Skip to content

Clean up error messages displayed in the error box - #756

Merged
bcotrim merged 7 commits into
trunkfrom
add/clean_error_messages
Dec 20, 2024
Merged

Clean up error messages displayed in the error box#756
bcotrim merged 7 commits into
trunkfrom
add/clean_error_messages

Conversation

@bcotrim

@bcotrim bcotrim commented Dec 19, 2024

Copy link
Copy Markdown
Contributor

Related issues

Proposed Changes

  • Adds optional "Open Studio Logs" button to error dialogs
  • Clean up error cleanup and logging logic away from showErrorMessageBox

image

Testing Instructions

Prerequisites

  • Pull the changes from this branch
  • Start Studio with npm start

Test Scenarios

  1. Error Dialog Display

    • Trigger an error (e.g., rename a server folder while app is running and try to start that server)
    • Verify the error dialog:
      • Shows message and error
      • Displays "Open Studio Logs" button when showOpenLogs is true
      • Shows "OK" button
  2. Log File Access

    • Click "Open Logs" button
    • Verify log file opens with complete error details
  3. Dialog Dismissal

    • Click "OK" button
    • Verify dialog closes properly

Expected Results

  • Error logging and message display responsibility have been moved away from showErrorMessageBox function
  • Developers are able to handle and parse error messages and choose what to display
  • Developers are able to offer the users the option to check logs when displaying error messages

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?
@bcotrim
bcotrim requested a review from a team December 19, 2024 20:58
Comment thread src/ipc-handlers.ts Outdated
Comment thread src/ipc-handlers.ts Outdated
);
await showMessageBox( event, {

console.error( filteredError );

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not make this method responsible of logging the error and leave it up for the caller.

Given #753, we could clean logic around filteredError and error in this method.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be preferable to display the error twice than none.
We could display some empty lines and a clear text in the log, like: "ERROR REPORTED:" or "ERROR OCCURRED:". This way the user and we would be much more sure about what error was the responsible of the alert.

Here is a possible implementation:

	const errorMessage = ( error as Error )?.message;
	if ( errorMessage ) {
		console.error( '\n\n\n\n\n\nERROR REPORTED:\n' + errorMessage );
	}

If we follow this path, we could rename the parameter name from error to errorToLog, so it's clear that the error will be logged in this function.

This is an example of how it would look:

Screenshot 2024-12-20 at 09 42 07

I also see Wojtek's point of view from the perspective of a single responsibility, so open to other ideas.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's remove the logging from this error and filteredError handling as those are solved outside the method scope.

Co-authored-by: Wojtek Naruniec <wojtek.naruniec@automattic.com>

@sejas sejas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, and it works as expected.
Not approving it until we decide if we should log or not the error.
I also see a possibility to display the first line of characters of the error inside the alert, that way users could share a screenshot of Studio too. But it's not a strong opinion.

I wonder if there are errors where we show the alert and we don't log them into the file. Then in those cases the "Open Studio logs" button would be misleading.

I only tested it on Mac:

Screenshot 2024-12-20 at 09 41 59

Clicking the Open Studio logs it opens the console app with the correct file almost at the bottom:

Screenshot 2024-12-20 at 10 24 06
Comment thread src/ipc-handlers.ts Outdated
);
await showMessageBox( event, {

console.error( filteredError );

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be preferable to display the error twice than none.
We could display some empty lines and a clear text in the log, like: "ERROR REPORTED:" or "ERROR OCCURRED:". This way the user and we would be much more sure about what error was the responsible of the alert.

Here is a possible implementation:

	const errorMessage = ( error as Error )?.message;
	if ( errorMessage ) {
		console.error( '\n\n\n\n\n\nERROR REPORTED:\n' + errorMessage );
	}

If we follow this path, we could rename the parameter name from error to errorToLog, so it's clear that the error will be logged in this function.

This is an example of how it would look:

Screenshot 2024-12-20 at 09 42 07

I also see Wojtek's point of view from the perspective of a single responsibility, so open to other ideas.

Comment thread src/ipc-handlers.ts Outdated
detail: error ? `${ message }\n\nError: ${ filteredError }` : message,
buttons: [ __( 'OK' ) ],
detail: message,
buttons: [ __( 'Open Studio logs' ), __( 'OK' ) ],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we display the "Open Studio logs" buttons in all the cases? or just when we receive the "errorToLog" parameter?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! We could use a param, e.g. showOpenLogs, that is set to false by default, and we can enable it per the case.

Comment thread src/ipc-handlers.ts
const response = await showMessageBox( event, {
type: 'error',
message: title,
detail: error ? `${ message }\n\nError: ${ filteredError }` : message,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's bring it back so the specific error can still be appended, but let's drop the 'Error: '.

Comment thread src/ipc-handlers.ts Outdated
);
await showMessageBox( event, {

console.error( filteredError );

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's remove the logging from this error and filteredError handling as those are solved outside the method scope.

Comment thread src/ipc-handlers.ts Outdated
detail: error ? `${ message }\n\nError: ${ filteredError }` : message,
buttons: [ __( 'OK' ) ],
detail: message,
buttons: [ __( 'Open Studio logs' ), __( 'OK' ) ],

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! We could use a param, e.g. showOpenLogs, that is set to false by default, and we can enable it per the case.

@wojtekn

wojtekn commented Dec 20, 2024

Copy link
Copy Markdown
Contributor

@bcotrim my bad, I was wrong on filteredError. This should stay as it filters ugly addition added by IPC Handler. I reverted this part and merged trunk in.

"Please verify your site's local path directory contains the standard WordPress installation files and try again. If this problem persists, please contact support."
),
error,
showOpenLogs: true,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm enabling a new button for cases in which Studio can't start the site.

Will add more under https://github.com/Automattic/dotcom-forge/issues/10143

@bcotrim
bcotrim merged commit 6d67471 into trunk Dec 20, 2024
@bcotrim
bcotrim deleted the add/clean_error_messages branch December 20, 2024 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants