Human Task Service proposal

[salaboy]

Here is the initial proposal for adding a new Human Task Service to complement the workflow functionality. I would appreciate feedback and comments. I can create a small PoC to demonstrate how this should work with some examples if the Dapr community thinks that these features would be helpful.

[olitomlinson]

Thanks Mauricio! Couple of initial thoughts....

Initially I thought I understood the value of the proposal, but after reading it through a couple of times, I'm struggling to understand what a Task actually is...

In my head, I see a Task as being very similar to a Child Workflow of a Parent Workflow. What am I missing here? What value does the Task offer that can't be developed as a Child Workflow? Using your example :

Tasks, because they have status associated to them, implement a simple lifecycle:

Created: this is the initial status of a task when it gets created.
Assigned: tasks needs to be assigned before they can be worked on. Assigning a task to an empty group/user will set the task back to Created status.
Started: A task must be started, before it is completed. Once the task is started, its payload can change.
Completed: A completed task cannot change it's payload.

Assigned and started could both be represented as custom status in a Child Workflow.

---

Maybe a more E2E pseudo-code example including GitHub issues would help make the cognitive leap to what you are thinking. I think this is what you are alluding to here :

To improve and prove the value of the APIs suggested in this proposal, a second implementation using GitHub issues can be implemented.

---

Other thoughts...

Initially, if the Query APIs from the Statestore offer enough functionality to start, I would suggest to implement a simple version of the service using a Statestore as persistent storage. If Query support is added to the in-memory Statestore, this would make an in-memory Human Task service possible.

I feel strongly to recommend not taking a dependency on the using State Store Query API for any part of this implementation, as the Query API is not going to graduate and is something that we dissuade the community from using, so we probably shouldn't use it internally either. I do understand that it being an internal detail, yes, it could be migrated away from in future without customer impact, but it still makes me uncomfortable to take a dependency on it given the negative sentiment given to it from several maintainers.

Scheduled Jobs/Tasks, Alerts and time-based reminders: there are very common business scenarios where tasks need to be automatically cancelled or reminders needs to be sent if a task hasn't been completed in a fixed amount of time. For such scenarios, integrations with the Dapr scheduler service are extremely good to have.

I see all the above as exactly why Workflows exists today, to orchestrate and co-ordinate business processes (much like any workflow / BPMN tool)

Notifications, Emails: there are well-known patterns to communicate with people, sending notifications (in app, SMS, or emails) are quite common requirements for the kind of functionalities described in this proposal. This highlight the need for what might become another Dapr building block to provide such functionality as APIs for developers to use.

Dapr Bindings already offer several Notification-based capabilities, I would recommend exploring integrating this proposal with Bindings in order to leverage existing art.