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

Hi @maxim is there a beta or rc available for us to test with?

Hi @frko

Development is in progress, but we don’t have an ETA yet

Antonio

Update-with-start is out in pre-release for Go users and, any day now, Java.
Typescript support is a priority, though we don’t have a date to announce at this time.