drush icon indicating copy to clipboard operation
drush copied to clipboard

Drush ErrorHandler intercepts trigger_error events, preventing external loggers (e.g. Sentry/Raven) from capturing them

Open superromeo opened this issue 3 months ago • 1 comments

Describe the bug Drush registers its own global ErrorHandler early in the runtime initialization process. This handler captures PHP native errors triggered via trigger_error() (such as E_USER_ERROR or E_USER_WARNING) to format and output them to the console.

However, this handler seems to stop the propagation of these errors to other registered handlers. As a result, integrations like the Raven module (Sentry) or other monitoring tools do not receive these error events when running code via Drush (e.g., via drush scr or custom commands).

While Throwable exceptions are correctly propagated and reported to external loggers, legacy trigger_error events are "swallowed" by Drush's handler and only appear in the CLI output.

To Reproduce

  1. Setup a Drupal instance with the raven module enabled (configured with a valid Sentry DSN).

  2. Create a PHP script (e.g., test_error.php) with the following content:

    <?php
    // This should be logged to Sentry
    trigger_error('Testing trigger_error via Drush', E_USER_ERROR);
    
  3. Run the script using Drush: drush scr test_error.php

  4. Check the Sentry dashboard.

Expected behavior The error is displayed in the CLI output AND reported to Sentry (and any other registered error handlers).

Actual behavior The error is displayed in the CLI output (formatted by Drush), but is NOT reported to Sentry.

Note: If the same code is executed via a web request (index.php), the error is correctly reported to Sentry.

Workaround Use throw new \Exception(...) or \Drupal::logger(...)->error(...) instead of trigger_error().

System Configuration

Drush version? 12.5

Drupal version? 10.3

PHP version 8.3

OS? Linux

Additional information The issue appears to stem from Drush\Runtime\Runtime::run, which calls doRun, and subsequently initiates the DI container setup.

In Drush\Runtime\Runtime.php:

// Our termination handlers are set up via dependency injection...
$this->di->installHandlers($container);

This calls Drush\Runtime\DependencyInjection::installHandlers, which activates the errorHandler service:

public function installHandlers($container): void
{
    foreach ($this->handlers as $handlerId) {
        $handler = $container->get($handlerId);
        $handler->installHandler();
    }
}

Since this happens before the command execution, Drush's handler takes precedence. If it returns true or stops propagation, subsequent handlers registered by Drupal modules (like Raven) are bypassed for trigger_error events.

superromeo avatar Nov 27 '25 14:11 superromeo

Help is appreciated here. Any PR should be against 14.x branch. Thanks.

weitzman avatar Nov 27 '25 15:11 weitzman