Workflow Invocation Methods

dbos-inc / dbos-transact

The TypeScript framework for backends that scale

https://docs.dbos.dev

MIT License

335 stars 22 forks source link

Workflow Invocation Methods #432

Closed kraftp closed 3 months ago

kraftp commented 3 months ago

This PR introduces two new methods for invoking workflows from handlers. For workflow bar in class Foo with argument arg:

ctxt.startWorkflow(Foo).bar(arg) starts the workflow and returns its handle. This is equivalent to the current ctxt.invoke(Foo).bar(arg).
ctxt.invokeWorkflow(Foo).bar(arg) executes the workflow and returns its result. This is equivalent to the current ctxt.invoke(foo).bar(arg).then((x)=>x.getResult()). The latter is very unintuitive and is tripping users up.

To avoid confusion, we also deprecate calling invoke on workflows--use one of the new methods instead.

My hope is that this makes it much clearer to users what is actually happening when a handler invokes a workflow.

chuck-dbos commented 3 months ago

Do we have an opportunity here to make invocation of child workflows have the same syntax as invoking workflows from the handler (and transactions and communicators also)?

qianl15 commented 3 months ago

Do we have an opportunity here to make invocation of child workflows have the same syntax as invoking workflows from the handler (and transactions and communicators also)?

This traced back to when we implemented child workflows. I tried to use the same invoke syntax but the issue was recursive return type inference loop. If developers forgot to specify a return type for a workflow, then Typescript compiler will complain "method doesn't exist on the return value of invoke()" for all workflows. The root cause was the WF invoke() would return itself so that the compiler will fall into a recursive loop to infer the return type: "implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions".

Back then we discussed a solution: we can enforce people to always explicitly specify the return type for a workflow.

chuck-dbos commented 3 months ago

This traced back to when we implemented child workflows. I tried to use the same invoke syntax but the issue was recursive return type inference loop.

So, if we could avoid this problem cleanly, then that is what we would want?

kraftp commented 3 months ago

This traced back to when we implemented child workflows. I tried to use the same invoke syntax but the issue was recursive return type inference loop.

So, if we could avoid this problem cleanly, then that is what we would want?

Yes, it would be much cleaner! Do you have an idea of how to do it? Harry tried back when we first did invoke and couldn't get past this problem, and I tried again as part of this PR and couldn't find a better solution.

chuck-dbos commented 3 months ago

Yes, it would be much cleaner! Do you have an idea of how to do it? Harry tried back when we first did invoke and couldn't get past this problem, and I tried again as part of this PR and couldn't find a better solution.

I would like time to take a shot at it tomorrow.