Bug #32961
closed
BE module list dies if a tasks class cannot properly be unserialized
Added by Mario Rimann almost 13 years ago.
Updated almost 11 years ago.
Description
This happened not the first time to me today, that the scheduler backend module throws just a white page. We could always solve this by cleaning out the task-records from the scheduler tasks table in the database.
Proposed change:
Make it a bit more robust to detect this problem, show a warning message
- Status changed from New to Accepted
- Assignee set to Francois Suter
Indeed this was improved already in the past, but apparently not enough. One typical situation is if a task's class signature has changed since it was first serialized.
I'll try to take a look at some point.
Hi Mario,
I finally took a look and I couldn't trigger such a mishap. Could it be related to #33116? Could you provide a test scenario?
Francois Suter wrote:
I finally took a look and I couldn't trigger such a mishap. Could it be related to #33116? Could you provide a test scenario?
I don't think it's directly related to #33116 by reading the bug report.
Also I'm not 100% sure what triggered the error. But I think it was one of the following:
- the scheduler task's class was removed (and the task record still points to it)
- the scheduler task's class was renamed (and the task record still points to the old name)
That happens if you have a syntax error (or any other fatal error). There is nothing TYPO3 can do about it, because fatal errors can not be catched.
If the class name does not exits, TYPO3 will display an error message.
This is a wontfix
Philipp Gampe wrote:
This is a wontfix
Agreed, then please close this issue.
- Status changed from Accepted to Rejected
- Category set to scheduler
- Project changed from 739 to TYPO3 Core
- Category changed from scheduler to scheduler
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by