Typo3Integration::setUrl() crashes with TypeError in CLI context when request has no URI

[konradmichalik]

Bug Report

Summary

Typo3Integration::processEvent() calls $request->getUri()->__toString() without handling the case where the URI is null. In CLI/cron context, certain TYPO3 extensions (e.g. codingms/openimmo) create a fake ServerRequest with applicationType=BE but without a URI set. This causes a TypeError that masks the original error Sentry is trying to report.

Steps to Reproduce

1. Run a TYPO3 scheduler task that sets $GLOBALS['TYPO3_REQUEST'] to a ServerRequest without URI but with applicationType=BE:

    ->withAttribute('applicationType', SystemEnvironmentBuilder::REQUESTTYPE_BE)
    ->withAttribute('site', $site);

2. Trigger any error during the task execution
3. Sentry's SentryLogWriter picks up the log entry and calls Typo3Integration::processEvent()
4. processEvent() detects isBackend() === true and calls setUrl()
5. setUrl() calls $request->getUri()->__toString() → getUri() returns null → TypeError

Expected Behavior

Sentry should gracefully handle a missing URI and either skip the URL enrichment or tag the event as cli.

Actual Behavior

  TypeError: TYPO3\CMS\Core\Http\Request::getUri(): Return value must be of type
  Psr\Http\Message\UriInterface, null returned
  in vendor/typo3/cms-core/Classes/Http/Request.php:287

  Stack trace:
  #0 Typo3Integration.php(63): Request->getUri()
  #1 Typo3Integration.php(46): setUrl()
  #2 Typo3Integration.php(31): processEvent()
  #3 Scope.php(468): {closure}()
  ...
  #10 SentryLogWriter.php(55): Client::captureMessage()

Suggested Fix

Add a try-catch in setUrl() or check for CLI context in processEvent():

  private function processEvent(Event $event): void
  {
      $request = $this->getServerRequest();
      if ($request instanceof ServerRequestInterface) {
          try {
              if (ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend()) {
                  $event->setTag('request_type', 'frontend');
                  $this->setUrl($event, $request);
              } elseif (ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isBackend()) {
                  $event->setTag('request_type', 'backend');
                  $this->setUrl($event, $request);
              }
          } catch (\TypeError) {
              if (Environment::isCli()) {
                  $event->setTag('request_type', 'cli');
              }
          }
      } elseif (Environment::isCli()) {
          $event->setTag('request_type', 'cli');
      }
      // ...
  }

Environment

• networkteam/sentry-client: 5.2.1
• TYPO3: 13.x
• PHP: 8.3+
• Context: CLI/Scheduler with codingms/openimmo ImportCommand

[thegass]

Easy fix should be

if (!Environment::isCli() && $request instanceof ServerRequestInterface) {

instead of

if ($request instanceof ServerRequestInterface) {

so that a 'fake' Request in cli context doesn't trigger that exception.

[s-ude]

We ran into the same issue. The 'fake' request seems to be an established pattern for CLI commands in TYPO3 and it is even used in some core extensions (typo3/cms-extensionmanager, typo3/cms-form). While adding a valid URL to the 'fake' request would prevent the exception from being thrown, it would still result in Sentry misinterpreting a CLI context as a backend context.

The fix looks good to me too.