Would "updateWithStart" make sense?

Now that Workflow Updates are landing in TS SDK (and Core!), I was thinking about supporting updateWithStart.

I’m thinking specifically about TS SDK since it’s the one I use the most but I’d say other SDKs would follow the same idea.

The client calls updateWithStart for a given workflow ID and, if one is running, it registers the update. If not, it starts the workflow with that given update request, and waits for the update to return.

So, basically the same idea behind signalWithStart. I can think of some use cases, e.g. a workflow that processes transactions for a given key serially. One could model this as a long running workflow, where each transaction is an update to a workflow with the key as the workflow id.

If you don’t have updateWithStart, you’d have to either check if the workflow is running and call startUpdate (or executeUpdate) or start the workflow and then call start/executeUpdate, which implies two round trips to the Temporal Server instead of one.

Yes, we are planning to implement UpdateWithStart with a semantic similar to SignalWithStart.

1 Like