Action <>Tasks communications

[damian...@gmail.com]

Hi

I have an Action that enqueues a Task. When that Task finishes its work at some later point is there a way for the Action that enqueued it to know? The callback to enqueue is for when the Task has successfully been enqueued, not when when it has competed. I understand that the Task calls next() but I can't see a why that I can plug into that...

[Michael Jensen]

Hi there!

It sounds like you have some work that is substantial, that you want to be able to initiate from an action and return to the user. I think there are a couple of gotchas with this approach that will possibly bite you:

1. A task may take a long time to process and your action handler might timeout (for web/http). This is not a huge deal, because you can control the timeouts, but might be relevant in some other situations
2. Tasks may not be processed by the same node that the action is being run on. This will be a bigger problem for calling back to your action code, especially because the task payload is serialized to javascript (so you can't really pass a function or promise object or similar). There are other ways to work around this (like a map of "transaction ID" to callback function that is set up before starting the task and then you pass the id to the task which invokes the callback when finished), but it gets very complicated when you're talking about distributed applications.

With that said, there are a couple of other options you have to for doing what your talking about:

• For short-running background tasks:
  I would suggest that you take the logic that your task does and move it into a helper. Change the task and action to both call the helper. This will save you the overhead of managing tasks and coordinating the communication, but you will still be subject to (1) if the "work" that the task does may take a long time.
• For longer-running background tasks:
  Structure your application around the user initiating "transactions". The action generates an ID (which is then stored in the database/redis/wherever) and initiates the task with the transaction id. The action then returns the ID to the user with a status code like 202 Accepted. When the task completes, it should store the result in your backend storage along with the transaction ID. You can then provide another action that allows the user to get the results at some time later. You could continue to return 202 until the actual result is ready to be sent to the client.

Hope this helps!

[Evan Tahler]

That's a solid answer.

Basically, actions respond to clients, and tasks are meant to be run asynchronously from that request.  Actions can enqueue a task, but you'll need to poll or otherwise notify the client (perhaps via web socket) when the job is done.

[Damian Norman]

Thanks for your help guys. Much appreciated.

-Damian