[Feature Request] TaskHandler should return the task_id if persistent.

Is your feature request related to a problem? Please describe.

There is currently no way to manage a persistent utils.delay() after a server has been reloaded.

Describe the solution you’d like

The TaskHandler add() method should return the task_id if the persistent kwarg is set to True.

Additional context

There is currently a remove() method that takes the task_id as an argument, but there is no way for the developer to gain access to the task_id when creating a utils.delay(). This change would greatly improve the usability of utils.delay() across a reload.

Chat conversation regarding this proposed change: https://irclogs.jackgrigg.com/irc.freenode.net/evennia/2021-04-07#i_4710369

[Griatch]

For example twisted’s deferLater method of getting the twist’s cancel method from the clock did not work. I had to rewrite deferLater to resolve it.

Not sure what you mean here - deferred.cancel() works just fine as far as I know? We use these tools a lot in Evennia and I’ve never had a need to rewrite something as fundamental as deferLater to work with it …

I think that breaking backwards compatibility and return the id rather than the defererred is ok in this case since currently the taskhandler.remove is just not usable. Not sure .chain is really needed (at least if I understand it as some sort of custom thing) - as long as you get the deferred you can use that to chain as much as you want. The simplest way forward here may be to just allow the user a new kwarg to choose to return the deferred if desired from .add, and maybe some new method to be able to retrieve the id and/or deferred from the handler on-demand if they want to do something with them.

[davewiththenicehat]

I am confident I could write it in. Though deferred has a lot of method. So task handler would have a get method to return a deferred.

It would also break anyone’s current code that relies on the returned deferred instance.