Feature #49071: SchedulerTask: Rethrow exceptions in task execution - TYPO3 Core - TYPO3 Forge

Custom queries

12 LTS
Accessibility
Dashboard issues
Easy tasks
Extbase Issues
FAL Issues
FAL Sprint 2023
Hierarchical Issues
Issues reported for v11
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
Most wanted Bugfixes
Most wanted Features
My open issues
New & Unassigned
No feedback within 90 days
Open Bugs
Open issues of 10
Page Tree Regressions after 2020-07-28
Recently modified
Regressions
Stabilization Issues
Usability or UX

Actions

Copy link

Feature #49071

closed

SchedulerTask: Rethrow exceptions in task execution

Added by Alexander Opitz almost 11 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Could have

Assignee:

Category:

Extbase

Target version:

7.1 (Cleanup)

Start date:

2013-06-12

Due date:

% Done:

100%

Estimated time:

PHP Version:

Tags:

Complexity:

Sprint Focus:

Description

If a task throws an exception, TYPO3\CMS\Extbase\Scheduler\Task catch it, log it and returns false.

As the Scheduler TYPO3\CMS\Scheduler\Scheduler handles exceptions in executeTask and shows the message of the exception in the backend and handles writing to log hisself, Extbase shouldn't return false. As the Scheduler uses at atm $GLOBALS['BE_USER']->writelog() and not \TYPO3\CMS\Core\Utility\GeneralUtility::sysLog() for logging, I would prefer to log self and rethrow the exception.

Would like to see this in 6.2 and 6.1.

Related issues 1 (0 open — 1 closed)

Related to TYPO3 Core - Task #47193: Move the extbase scheduler to the scheduler extension

Closed

2013-04-13

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Marc Bastian Heinrichs almost 11 years ago

Category set to Extbase
Priority changed from Should have to Could have
Target version set to Extbase 6.2

Actions

Copy link

Updated by Alexander Opitz over 9 years ago

Project changed from 534 to TYPO3 Core
Category changed from Extbase to Extbase
Target version changed from Extbase 6.2 to 7.0

Actions

Copy link

Updated by Stephan Großberndt over 9 years ago

Since once again I had a hard time finding out why an Extbase CommandController failed:

As found out by Alexander, if a task throws an exception, TYPO3\CMS\Extbase\Scheduler\Task catches it, logs it and returns false.

Logging is only done if [SYS][systemLog] has a value set (file|mail|syslog|error_log) - which is not the case in a default installation - not even in development context!
So normally this information is just silently dropped, thus I would not consider this as a feature request but as a bug.

Logging to the systemLog is fine, but the information should be thrown again afterwards, otherwise the only message you will see when executing a Task with an error:

Execution of task "Extbase CommandController Task (extbase)" failed with the following message: Task failed to execute successfully. Class: TYPO3\CMS\Extbase\Scheduler\Task, UID: 3

Oh, really, it failed with the message "failed to execute"? Very helpful..

Using

throw $e

after logging to systemLog instead of

return FALSE;

gives the reason of failure:

Execution of task "Extbase CommandController Task (extbase)" failed with the following message: PHP Warning: mssql_pconnect(): message: Cannot open user default database. Login failed. (severity 11) in xxx line 123

as well when executing the task manually from the BE-scheduler as in the BE-log when executed via cli_dispatch scheduler

Actions

Copy link

Updated by Stephan Großberndt over 9 years ago

I tried to commit this as a change but I could not upload (maybe due to not having signed the CLA?).

If someone from the extbase team could commit this please?

[BUGFIX] Rethrow exceptions in task execution of SchedulerTask

Rethrow exceptions from tasks inheriting from Extbase-SchedulerTask 
instead of just returning false.

The logging in TYPO3\CMS\Extbase\Scheduler\Task happens only if 
[SYS][systemLog] has a value set (file|mail|syslog|error_log) - which is
not the case in a default installation. So this information is just 
silently dropped at the moment.

When returning false the unhelpful message in the BE log is "Task failed
to execute successfully." Rethrowing the exception gives the reason of 
failure instead as well when executing the task manually from the 
BE-scheduler as in the BE-log when executed via cli_dispatch scheduler

Resolves: #49071
Releases: master, 6.2

Actions

Copy link

Updated by Mathias Schreiber over 9 years ago

Target version changed from 7.0 to 7.1 (Cleanup)

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/36985

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/36985

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/36985

Actions

Copy link

Updated by Gerrit Code Review about 9 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37355

Actions

Copy link

#10