Scheduler cannot handle large Exceptions
When a Task fails with a very long Exception message (say a few thousand lines), the scheduler mod will not load and display an error message:
Fatal error: Call to a member function getCode() on a non-object in /var/www/domains/schrittauftritt.ch/typo3/sysext/scheduler/mod1/index.php on line 1087
I iterate over several thousand fe_users in a reminder task and log some lines for each user (along the lines of: User xy with uid N will be reminded or Email failed/succeeded etc).
I used this when I was programming the Task, but I found it useful to include in the error message.
However, the db-field lastexecution_failure (type text) is too small to store large serialized Exceptions.
So when the scheduler tries to unserialize them, the result will be null (as shown by the Fatal error).
Solution (either or both):
- Use a bigger db-field (MEDIUMTEXT or LONGTEXT)
- Make sure the unserialized object checked for null
(issue imported from #M14184)
Updated by Christian Kuhn almost 11 years ago
Hmm, I'm unsure if we should really make the field much bigger. It's currently TEXT, and I think 65k of data is plenty in this case.
If you want to log that much data, it might be a better solution to create a special log table with some structure (eg. with fields for task date, user id and message), and create some be-module to show this data. Or you could stuff your data into a mail and send it to some admin account.
But it's a bug that the scheduler doesn't crop the exception to a max length to ensure a non-broken serialization. That should be fixed.
Updated by Francois Suter over 10 years ago
This is my proposal: do nothing upon serializing, but rather test the result of unserializing. If it fails, instead of the error message stored in the Exception object, we display a message to the effect that the Exception object was badly stored so the error could not be retrieved. It seems simpler to me.
Updated by Nils Blattner over 10 years ago
I agree Francois. That would be the proper way imo.
The returned value would be FALSE, and since you serialize an object the return should never be false except when it failed.
From how I understand TEXT/BLOB storage, MEDIUM-/LONGTEXT only requires more storage size than TEXT if the extra space is actually filled.
TBE it's stored separatly blockwise with a reference to that in the row.
Thus while the exception text were small, the same amount of storage is used as with a normal TEXT type but would allow for much larger exceptions aswell to be stored.
However the issue with the call on a non-object should still be solved.