Skip to content

[Messenger] improve logs #32036

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

Merged
merged 1 commit into from
Jun 14, 2019
Merged

[Messenger] improve logs #32036

merged 1 commit into from
Jun 14, 2019

Conversation

Tobion
Copy link
Contributor

@Tobion Tobion commented Jun 14, 2019

Q A
Branch? 4.3
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

The logs are currently very confusing and duplicated:

  • When handled sync the uncaught error it logged and displayed by the console / http error handler anyway. Currently it the warning is duplicated and useless:
14:26:11 WARNING   [messenger] An exception occurred while handling message "{class}": OUCH, THAT HURTS! GO TO MOM! 
14:26:11 ERROR     [console] Error thrown while running command "{class}". Message: "OUCH, THAT HURTS! GO TO MOM!"

In HandleMessageMiddleware.php line 82:

  [Symfony\Component\Messenger\Exception\HandlerFailedException]
  OUCH, THAT HURTS! GO TO MOM!
  • When handling async is was even confusing because the actual error was logged as warning and the retry (which is a good thing) was the error.
13:48:15 WARNING   [messenger] An exception occurred while handling message "{class}": OUCH, THAT HURTS! GO TO MOM! 
13:48:15 ERROR     [messenger] Retrying {class} - retry #1.

Now it's must clearer and adds even context like the delay:

16:20:11 ERROR     [messenger] Error thrown while handling message {class}. Dispatching for retry #3 using 4000 ms delay. Error: "OUCH, THAT HURTS! GO TO MOM!"
...
16:20:15 CRITICAL  [messenger] Error thrown while handling message {class}. Removing from transport after 3 retries. Error: "OUCH, THAT HURTS! GO TO MOM!"

@@ -75,7 +75,7 @@ public function handle(Envelope $envelope, StackInterface $stack): Envelope
throw new NoHandlerForMessageException(sprintf('No handler for message "%s".', $context['class']));
}

$this->logger->info('No handler for message "{class}"', $context);
$this->logger->info('No handler for message {class}', $context);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed quotes for consistency. They are not useful in logs because in cli they are colored due to the context and the class is a very fixed string anyway without whitespace.

}
} catch (\Throwable $e) {
$context['exception'] = $e;
$this->logger->warning('An exception occurred while handling message "{class}": '.$e->getMessage(), $context);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just removing the try catch. It's usually not a good idea to both log and re-throw because it created duplicate logs.

@@ -157,7 +159,7 @@ private function handleMessage(Envelope $envelope, ReceiverInterface $receiver,
$receiver->ack($envelope);
} else {
if (null !== $this->logger) {
$this->logger->critical('Rejecting {class} (removing from transport).', $context + ['error' => $throwable]);
$this->logger->critical('Error thrown while handling message {class}. Removing from transport after {retryCount} retries. Error: "{error}"', $context + ['retryCount' => $retryCount, 'error' => $throwable->getMessage(), 'exception' => $throwable]);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

including the exception message makes sure you can see it without having to run in -vvv mode. the context otherwise only shows the exception class but not the message.

@fabpot
Copy link
Member

fabpot commented Jun 14, 2019

Thank you @Tobion.

@fabpot fabpot merged commit 2ac7027 into symfony:4.3 Jun 14, 2019
fabpot added a commit that referenced this pull request Jun 14, 2019
This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] improve logs

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License       | MIT
| Doc PR        |

The logs are currently very confusing and duplicated:

- When handled sync the uncaught error it logged and displayed by the console / http error handler anyway. Currently it the warning is duplicated and useless:

```
14:26:11 WARNING   [messenger] An exception occurred while handling message "{class}": OUCH, THAT HURTS! GO TO MOM!
14:26:11 ERROR     [console] Error thrown while running command "{class}". Message: "OUCH, THAT HURTS! GO TO MOM!"

In HandleMessageMiddleware.php line 82:

  [Symfony\Component\Messenger\Exception\HandlerFailedException]
  OUCH, THAT HURTS! GO TO MOM!
```

- When handling async is was even confusing because the actual error was logged as warning and the retry (which is a good thing) was the error.

```
13:48:15 WARNING   [messenger] An exception occurred while handling message "{class}": OUCH, THAT HURTS! GO TO MOM!
13:48:15 ERROR     [messenger] Retrying {class} - retry #1.
```

Now it's must clearer and adds even context like the delay:

```
16:20:11 ERROR     [messenger] Error thrown while handling message {class}. Dispatching for retry #3 using 4000 ms delay. Error: "OUCH, THAT HURTS! GO TO MOM!"
...
16:20:15 CRITICAL  [messenger] Error thrown while handling message {class}. Removing from transport after 3 retries. Error: "OUCH, THAT HURTS! GO TO MOM!"
```

Commits
-------

2ac7027 [Messenger] improve logs
@Tobion Tobion deleted the messenger-logs branch June 14, 2019 11:33
@fabpot fabpot mentioned this pull request Jun 26, 2019
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.

3 participants