taskhandler verified do_task causes errors if called manually (early)

Any usage of taskhandler's method outside of the deferred instance calling it results in errors.

Referencing: It's easier to access these tasks (should it be necessary) using
    `evennia.scripts.taskhandler.TASK_HANDLER`
I can see it is intended to be used this way.

More importantly usage of the global reactor would require usage of reactorbuilder API which is recomended for building reactors only.

Commiting notes before switching to twisted's documented methods for making and testing deferrals.
In short I need to get an instance of reactor's callLater. Creating and working with that call later will allow me to test taskhandler and make it function as intended.

Usage of utils.delay will not change.
This commit is contained in:
davewiththenicehat 2021-04-13 17:01:55 -04:00
parent f445cfb355
commit f62ff2015f
3 changed files with 78 additions and 6 deletions

View file

@ -1022,7 +1022,7 @@ _TASK_HANDLER = None
def delay(timedelay, callback, *args, **kwargs):
"""
Delay the return of a value.
Delay the calling of a callback (function).
Args:
timedelay (int or float): The delay in seconds
@ -1040,15 +1040,26 @@ def delay(timedelay, callback, *args, **kwargs):
commandhandler callback chain, the callback chain can be
defined directly in the command body and don't need to be
specified here.
Reference twisted.internet.defer.Deferred
if persistent kwarg is truthy:
task_id (int): the task's id intended for use with
evennia.scripts.taskhandler.TASK_HANDLER's do_task and remove methods.
Note:
The task handler (`evennia.scripts.taskhandler.TASK_HANDLER`) will
be called for persistent or non-persistent tasks.
If persistent is set to True, the callback, its arguments
and other keyword arguments will be saved in the database,
and other keyword arguments will be saved (serialized) in the database,
assuming they can be. The callback will be executed even after
a server restart/reload, taking into account the specified delay
(and server down time).
Keep in mind that persistent tasks arguments and callback should not
use memory references.
If persistent is set to True the delay function will return an int
which is the task's id itended for use with TASK_HANDLER's do_task
and remove methods.
All task's whose time delays have passed will be called on server startup.
"""
global _TASK_HANDLER