Logger instances in scheduler tasks are deserialized with outdated paths
Scheduler serializes tasks and stores them in the database.
If these tasks store a logger instance (e.g. by using the LoggerAwareTrait), this instance will be serialized as well and will point to the wrong path, e.g. when TYPO3 is moved to a different folder
or path changes due to deployments.
This issue became much more prevalent with the addition of LoggerAwareTrait to \TYPO3\CMS\Scheduler\Task\AbstractTask
Now every single task will store outdated logger instances pointing to very likely broken directories
#6 Updated by Helmut Hummel 11 days ago
@Benni: Depends how you look at it. https://review.typo3.org/#/c/Packages/TYPO3.CMS/+/59800/ shows, that the implemented solution needs adaption in all scheduler tasks that implement __sleep and/or __wakeup. e.g. AbstractSolrTask implements __sleep which does not reset the logger, which leads to the logger to be serialized again and not properly set in __wakeup because the logger is only restored when property is null.
Thus https://review.typo3.org/#/c/Packages/TYPO3.CMS/+/59259/ appeared, which introduces an upgrade wizard to remove the logger from serialized tasks, which basically needs to be run all the time, not only once so that solr tasks have a proper instance.
This is why I proposed several times to remove the logger in \TYPO3\CMS\Scheduler\Task\AbstractTask::unsetScheduler and restore it in \TYPO3\CMS\Scheduler\Task\AbstractTask::setScheduler, which solves all issues (makes 59259 obsolete) and also is a more stable solution as it is much more unlikely that custom task implementations override unsetScheduler and setScheduler methods.
So yes, it is partly solved, but the solution is not as robust as it could be. I would do a change request, but since my comments were ignored as of now, I didn't feel like fighting for this one.