Workflow Invocation Methods

[kraftp]

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]

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]

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]

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]

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]

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.

[maxdml]

tbh invokeWorkflow doesn't really convey the synchronous aspect of the call. What about something super explicit like runWorkflowToCompletion or startWorkflowSync, invokeWorkflowAndWait ?

[kraftp]

People intuitively expect invocation to be synchronous (invoke itself is synchronous) so calling it invokeWorkflow is clear, anything more complex may be confusing.