Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symfony compliant error handling #18790

Merged

Conversation

cedric-anne
Copy link
Member

@cedric-anne cedric-anne commented Jan 22, 2025

Checklist before requesting a review

  • I have read the CONTRIBUTING document.
  • I have performed a self-review of my code.
  • I have added tests that prove my fix is effective or that my feature works.
  • This change requires a documentation update.

Description

The Symfony error handler and our own error handler are currently executed in parallel. It result in unexpected side effects, including:

  • lack of logging for error/exceptions that are triggered during the Symfony container compilation;
  • blank error page on some edge cases;
  • duplication of some logged messages.

The purpose of this PR is to extend the Symfony error handler to reproduce the behaviour of our own legacy error handler., in order to fix these side effects.

Also, error messages are now only output when it is relevant. There is no need to manually call the disableOutput() method to prevent outputing messages in a non HTML context.

I was able to remove the Kernel::sendRequest() method, as the exceptions thrown during the response sending are now correctly caught.

I took the opportunity to add a test validating the format of our php-errors.log file. This file is probably parsed by some scripts and it is preferable to make its format stable over time. Testing the error handler itself is a bit complex (it would probably require a specific E2E test to check logs) and, as it extends the Symfony base handler, most of the code is already tested by Symfony itself.

It is based on #18696 .

@AdrienClairembault
Copy link
Contributor

Need a rebase since #18801 was merged.

/**
* GLPI (instantiation and so on)
**/
* @FIXME Find a better place for these constants.
Copy link
Contributor

Choose a reason for hiding this comment

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

Which constants are you talking about ?

Copy link
Member Author

Choose a reason for hiding this comment

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

This class only contains constants now.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. Well I guess we can just rename it and turn it into an enum.

@cedric-anne cedric-anne merged commit 576fcd0 into glpi-project:main Jan 23, 2025
9 checks passed
@cedric-anne cedric-anne deleted the 11.0/symfony-error-handler branch January 23, 2025 17:24
@@ -47,6 +47,9 @@
$parameters->set('env(APP_SECRET_FILE)', $projectDir . '/config/glpicrypt.key');
$parameters->set('kernel.secret', env('default:glpi.default_secret:file:APP_SECRET_FILE'));

// Prevent low level errors (e.g. warning) to be converted to exception in dev environment
Copy link
Contributor

Choose a reason for hiding this comment

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

This is because of a too high number of this errors ?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, it is because we used to use warnings in GLPI for non blocking errors, and I wanted to preserve this behaviour for the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants