---
title: "Breaking: #110219 - Log request ID provided by log processor"
manual: "TYPO3 Core Changelog"
version: "main"
permalink: "https://docs.typo3.org/permalink/changelog:breaking-110219-1784306184"
source: "Changelog/15.0/Breaking-110219-LogRequestIdProvidedByLogProcessor.rst"
typo3-version: "15.0"
typo3-major: 15
type: "breaking"
issue: 110219
forge: "https://forge.typo3.org/issues/110219"
tags: ["PHP-API", "NotScanned", "ext:core"]
rendered: "2026-10-07T18:53:34+00:00"
---

# Breaking: #110219 - Log request ID provided by log processor {#breaking-110219-1784306184}

See [forge#110219](https://forge.typo3.org/issues/110219)

## Description {#description}

The unique ID of the current request, used to correlate all log entries
written during a single request, was previously passed as constructor
argument from `\TYPO3\CMS\Core\Log\LogManager` to every
`\TYPO3\CMS\Core\Log\Logger` instance, which in turn copied it into
each created `\TYPO3\CMS\Core\Log\LogRecord`.

The request ID is now added to log records at logging time by the new log
processor `\TYPO3\CMS\Core\Log\Processor\RequestIdProcessor`, which
`\TYPO3\CMS\Core\Log\LogManager` attaches automatically to every logger it creates, for
all severity levels covered by the configured log writers. The processor
is registered internally on purpose — not via
`$GLOBALS['TYPO3_CONF_VARS']['LOG']` — so it cannot be removed
accidentally by overriding the global processor configuration.

The following method signatures have changed:

-   `\TYPO3\CMS\Core\Log\Logger::__construct()` no longer accepts a second
    `$requestId` argument, the protected property
    `\TYPO3\CMS\Core\Log\Logger::$requestId` has been removed
-   `\TYPO3\CMS\Core\Log\LogManager::__construct()` now expects a
    `\TYPO3\CMS\Core\Core\RequestId` object instead of a string, and
    creates one itself if omitted
-   The protected method `\TYPO3\CMS\Core\Log\LogManager::makeLogger()` no longer receives
    a `$requestId` argument

The generated log output is unchanged: log records written by configured
writers carry the same request ID as before, available via
`\TYPO3\CMS\Core\Log\LogRecord::getRequestId()`.

## Impact {#impact}

Instantiating `\TYPO3\CMS\Core\Log\LogManager` with a string request ID will raise a PHP
`\TypeError`.

Passing a second argument to the `\TYPO3\CMS\Core\Log\Logger` constructor is ignored.
Log records created by a manually instantiated `\TYPO3\CMS\Core\Log\Logger` — bypassing
`\TYPO3\CMS\Core\Log\LogManager` — no longer contain a request ID, unless the
`\TYPO3\CMS\Core\Log\Processor\RequestIdProcessor` is attached manually.

## Affected installations {#affected-installations}

TYPO3 installations with third-party extensions instantiating
`\TYPO3\CMS\Core\Log\Logger` or `\TYPO3\CMS\Core\Log\LogManager` directly with a custom request ID,
which is very unlikely. Extensions obtaining loggers via dependency
injection, the `#[Channel]` attribute, `\Psr\Log\LoggerAwareInterface`
or `\TYPO3\CMS\Core\Log\LogManager->getLogger()` are not affected.

## Migration {#migration}

Obtain loggers through dependency injection or
`\TYPO3\CMS\Core\Log\LogManager->getLogger()`, which attach the
`\TYPO3\CMS\Core\Log\Processor\RequestIdProcessor` automatically.

For manually created loggers that should add the request ID to their
log records, attach the processor explicitly:

```php
use TYPO3\CMS\Core\Core\RequestId;
use TYPO3\CMS\Core\Log\Logger;
use TYPO3\CMS\Core\Log\LogLevel;
use TYPO3\CMS\Core\Log\Processor\RequestIdProcessor;

$logger = new Logger('my.channel');
$logger->addWriter(LogLevel::WARNING, $myWriter);
$logger->addProcessor(LogLevel::WARNING, new RequestIdProcessor(new RequestId()));
```