🇺🇦Ukraine @mr_fenix

So, here I attached a patch that will fix this.
Thanks.

mr_fenix → created an issue.

Hello,
There's really the issue and MR 25 completely works for me. Also langcode and bundle properties look necessary there.
Thanks

Unfortunately, there is a third error that will appear and prevent to test

InvalidArgumentException: The timestamp must be numeric. in Drupal\Component\Datetime\DateTimePlus::createFromTimestamp() (line 201 of /var/www/html/web/core/lib/Drupal/Component/Datetime/DateTimePlus.php).

The patch attached to the comment will fix this issue too.
And as a result it will be possible to see the result of all previous fixes on UI too.

Please use the same reproduction for the error.

This will be difficult to test because another error will appear there.

Error: Call to a member function id() on null in Drupal\user_revision\Form\UserRevisionRevertForm->buildForm() (line 102 of /var/www/html/web/modules/contrib/user_revision/src/Form/UserRevisionRevertForm.php).

Error: Call to a member function id() on null in Drupal\user_revision\Form\UserRevisionDeleteForm->buildForm() (line 96 of /var/www/html/web/modules/contrib/user_revision/src/Form/UserRevisionDeleteForm.php).

Please use the same steps to reproduce it.
The attached to this comment patch will fix it.

This patch will fix the dependency and argument constructor bug.

mr_fenix → created an issue.

driverok → credited mr_fenix → .

Hello,

I have reviewed this issue to be helpful, and it appears to me that this patch does not resolve the issue for the following reasons:

1. There is no need to add this parameter because it's already accounted for in the \Drupal\Core\Utility\Error::logException and \Drupal\Core\Utility\Error::decodeException methods.

2. Honestly, this issue doesn't seem to be a problem with the core as Drupal loggers don't use this in formatting https://git.drupalcode.org/project/drupal/-/blame/10.1.1/core/lib/Drupal...
without this
https://git.drupalcode.org/project/drupal/-/blob/10.1.2/core/lib/Drupal/...
for indices severity_level and exception (see the decodeException method).
So, I think you're using a logger specific to your system that uses FormattableMarkup (possibly indirectly), which doesn't parse $context with LogMessageParser::parseMessagePlaceholders first.

3. In any case, starting from the core version 10.1.5, the formatter has been changed https://git.drupalcode.org/project/drupal/-/blame/10.1.5/core/lib/Drupal... ,
and now there's no chance to get such warnings when these variable keys don't match.

Therefore, I suggest just close this issue, because the parameter already supposed to be added in code and in core 10.1.5, it works as expected (without warnings, please see FormattableMarkup), even if FormattableMarkup are used incorrectly. For lower version it seems it should be used correctly.

Thanks

Hello,

I have tested this with Drupal 9.3 (with a standard profile), PHP 7.4, and filelog 2.0.x-dev(Currently it also is applicable to other versions)

I was not able to reproduce the exactly same error inside the method cache Drupal\Core\Cache\DatabaseBackend->getMultiple() following the information given here, also it seems complex tokens of the type [log:user:url] were used. However,but i am sure the idea is the filelog does not report errors from the PageCache MiddleWare service. Indeed this is the case - I've tested it.

When the Drupal\page_cache\StackMiddleware\PageCache->handle service is invoked, all services are initialized at this stage, but the files of type tokens.module (*.module) are not loaded yet (hook_tokens won't work in these files - core tokens functionality purely support early calls too), so this error is a result of the token module not supporting calls at early stages (as it uses functions from the token.module file), and you could test this simply by uninstalling the token module for example.

Also, there is another problem. When an error is logged from the PageCache MiddleWare service at this stage, the "public" Stream Wrapper is not initialized yet, and as a result, if the root directory is writable, a folder named logs will be created in the web directory's root and all subsequent errors in this request will be logged in logs/drupal.log in the web directory. Maybe a check needs to be done for the existence of the "public" Stream Wrapper before opening the file for writing.

Summarizing:
1. Early calls support seems to need to be fixed in the Token module.
2. This patch is a partial solution, the error in the log file is still not logged when it appears at the early stages of PageCache MiddleWare Service.
3. When the public Stream Wrapper is not defined, errors are logged in a different place - web/logs/drupal.log

So, the patch #5 needs to be updated according to point (3) at least. Ideally, there should be a functionality to log to the drupal.log file (2), or get it ignored if the token module gets fixed and starts supporting calls from MiddleWare services (for those running before Drupal\Core\DrupalKernel MW) (1).
Also, I will add that after this patch implementation if an error occurs during token processing, that error will be logged only in the PHP error log instead of the drupal.log file, which also seems to need to be fixed. For this, the module's functionality might need to be changed to create its own token processing system, to be only partially dependent on the token functionality, and when there is an error in token parsing, to have the ability to log this also to the drupal.log file, using an alternative (implementable without the Token module functionality) error message formatting.

Thanks

Hello,

dblog and filelog modules work a bit differently. dblog simply writes errors to a database, but filelog not only logs errors to a file, it also formats them using token module's functionality. This means that all modules providing tokens for this module must do it absolutely without errors.

In your case, you changed not just any file, but a Drupal core file, which is necessary for the entities to function. As a result, this https://git.drupalcode.org/project/filelog/-/blame/2.0.x/filelog.tokens....
causes an issue described here.
When incorrect syntax is used outside the core, there is no behavior like this.

Since it is assumed that core files will never have the parse issue specified here, I'm not sure if this can be interpreted as an bug and if it makes sense to change it.

If you frequently encounter parsing issues within the core, a workaround could be using the [user:uid] token instead [log:user] inside format string.

If someone believe it is issue please change status.

I managed to reproduce it stably and the patch works perfectly. Thanks!

Here is the dependent service that is implemented using the interface
https://git.drupalcode.org/project/drupal/-/blob/10.2.2/core/modules/lay...

It also seems that the error could be interpreted as a bug in the Drupal core, or could even be interpreted as a flaw in the Drupal dependency injection concept.

I cannot confirm the issue after a basic installation of Drupal with the standard profile, version 10.2.2, and PHP version 8.2.14. Here are the steps I followed:

1. Installed and enabled Filelog module, version 2.1.1.
2. Cleared the cache.
3. Then, I removed the Contact module.
4. Cleared the cache again.
5. Checked admin/reports/dblog log
No errors were found as described in the issue.

Therefore, maybe it's better to identify the root of the problem before merging this, as it might turn out that instead of the Filelog module, the Token module or some other module needs to be fixed.

Moreover, it seems the 'cache_tags.invalidator' service should not depend on 'plugin.manager.block', because after running the Drush command:

drush ev '
  $database = \Drupal\Core\Database\Database::getConnection();
  $service_name = "token";
  $partial_cid = "service_container:%";
  // It is supposed the cache_container table is used.
  $query = $database->select("cache_container", "c")
    ->fields("c", ["data"])
    ->condition("cid", $partial_cid, "LIKE");
  $result = $query->execute();

  if ($record = $result->fetchAssoc()) {
    $container = unserialize($record["data"]);
    if (isset($container["services"][$service_name])) {
      $service_definition = unserialize($container["services"][$service_name]);
      echo  var_export($service_definition, TRUE);
    } else {
      echo "Service $service_name not found in the cache_container.\n";
    }
  } else {
    echo "No matching $partial_cid entry found in cache_container.\n";
  }'

result was:

array (
  'class' => 'Drupal\\Core\\Utility\\Token',
  'arguments' => 
  (object) array(
     'type' => 'collection',
     'value' => 
    array (
      0 => 
      (object) array(
         'type' => 'service',
         'id' => 'module_handler',
         'invalidBehavior' => 1,
      ),
      1 => 
      (object) array(
         'type' => 'service',
         'id' => 'cache.default',
         'invalidBehavior' => 1,
      ),
      2 => 
      (object) array(
         'type' => 'service',
         'id' => 'language_manager',
         'invalidBehavior' => 1,
      ),
      3 => 
      (object) array(
         'type' => 'service',
         'id' => 'cache_tags.invalidator',
         'invalidBehavior' => 1,
      ),
      4 => 
      (object) array(
         'type' => 'service',
         'id' => 'renderer',
         'invalidBehavior' => 1,
      ),
    ),
     'resolve' => true,
  ),
  'arguments_count' => 5,
)

So, there is no 'plugin.manager.block' service and it should not be in your installations either.

Can anyone experiencing this issue post result of the command here to confirm it?