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

Only assume important log encountered when log level is >= WARN #16735

Merged
merged 1 commit into from Nov 18, 2020

Conversation

tsteur
Copy link
Member

@tsteur tsteur commented Nov 18, 2020

Description:

Prevents an issue where it assumes that a command had an important log even when $log->info() is called under circumstances.

This is my DI config:

'log.handlers' => \DI\decorate(function ($handlers, ContainerInterface $container) {
        if (\Piwik\SettingsServer::isArchivePhpTriggered()
            || (\Piwik\Common::isPhpCliMode() && isset($_SERVER['argv']) && in_array('core:archive', $_SERVER['argv']))) {
            $handler = new \Piwik\Plugins\Monolog\Handler\EchoHandler();
            $passthruLevel = \Piwik\Container\StaticContainer::get('log.level');

            $handler->setLevel(\Monolog\Logger::DEBUG);

            $handler = new \Monolog\Handler\FingersCrossedHandler($handler, $activationStrategy = null, $bufferSize = 0,
                $bubble = true, false, $passthruLevel);

            $handlers = array_merge([$handler], $handlers ?: []);
        }
        return $handlers;
    }),

Basically my handlers look like this:

image

What is happening is that FingersCrossedHandler is the first handler and always returns true in $handler->isHandling() therefore the isHandling method on the FailureLogMessageDetector is never called because Monolog stops as soon as one handler is returning true for isHandling see https://github.com/Seldaek/monolog/blob/1.25.5/src/Monolog/Logger.php#L303-L306

By adding this extra line we make sure to only show this message (Error: error or warning logs detected, exit 1 ) and only change exit code if there's actually a warning or error no matter what handlers are defined.

This is needed for the cloud otherwise our exit codes are no longer reliable as many commands simply log an info etc. Eg before $this->logger->info("Archiving stopped by stop archiver exception"); would cause the exit code to be changed to 1 when this should not be the case.

We could maybe workaround it by adding fingerscrossedhandler to the end of handlers but not sure if this has other side effects and this way it always simply works.

Review

  • Functional review done
  • Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
  • Security review done see checklist
  • Code review done
  • Tests were added if useful/possible
  • Reviewed for breaking changes
  • Developer changelog updated if needed
  • Documentation added if needed
  • Existing documentation updated if needed

@tsteur tsteur added the Needs Review PRs that need a code review label Nov 18, 2020
@tsteur tsteur added this to the 4.0.0-RC milestone Nov 18, 2020
@tsteur tsteur added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Nov 18, 2020
@@ -28,7 +28,9 @@ public function __construct($level = Logger::WARNING)

public function handle(array $record)
{
$this->hasEncounteredImportantLog = true;
if ($this->isHandling($record)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

can't think of a case where it would hurt to have this in there and fixes the bug where isHandling might be ignored

@diosmosis
Copy link
Member

looks good

@diosmosis diosmosis merged commit 7c3d9f1 into 4.x-dev Nov 18, 2020
@diosmosis diosmosis deleted the loglevelwarn branch November 18, 2020 03:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Review PRs that need a code review not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants