[giosh94mhz]

Description

ExceptionToSentryIssueHandler extends AbstractHandler, so it has no processor stack: processors pushed on the handler, or configured on it by a framework integration, never run. The visible effect is that the monolog.message extra keeps the raw PSR-3 template instead of the interpolated message, and any extra data added by a processor is lost.

$handler = new ExceptionToSentryIssueHandler($hub);
$handler->pushProcessor(new PsrLogMessageProcessor()); // Error: undefined method

$logger->error('Failed to sync user {username}', [
    'username' => 'john',
    'exception' => $e,
]);
// monolog.message: "Failed to sync user {username}"

LogToSentryIssueHandler, and the deprecated Handler that both replace, extend AbstractProcessingHandler, so switching from Handler to the new pair makes the exception events lose the interpolated message, while the log events keep it.

This PR makes ExceptionToSentryIssueHandler extend AbstractProcessingHandler and use CompatibilityProcessingHandlerTrait, the same way LogToSentryIssueHandler does:

• handle() keeps its existing checks: records without a Throwable in context.exception, or below the level, are still skipped and return false. Otherwise it delegates to parent::handle(), which runs the processors and handles bubbling.
• The capture logic moves to doWrite(). It reads the exception again from the processed record and returns early if a processor removed it.

Issues

• related (deprecation): ref: deprecate old sentry handler #2051
• related: feat(monolog): add handler to only capture exceptions #2061
• related feat: add handler to convert logs to sentry issues #2075

[Litarnus]

Nice catch, thanks for opening the PR