Problematic update strategies when using WaitForExternalEvent

[jsommr]

I want to start out by saying I think the abstraction, durable execution, is great. The platform by MS scales well and the SDK is a pleasure to use. But what keeps me from using DF for anything more than simple, non-critical tasks is the fact that changing an orchestration without breaking those that are running, can be extremely hard. And what I hope is, that I'm just misunderstanding something.

Microsoft recommends side-by-side deployments in this document:

Deploy all the updates as entirely new functions, leaving existing functions as-is. This generally isn't recommended because of the complexity involved in recursively updating the callers of the new function versions.

Versioning the entire flow including all types and activities is indeed cumbersome. Doable for tiny orchestrations, but quickly becomes a burden when they grow in complexity.

Deploy all the updates as a new function app with a different storage account.

and

Deploy a new copy of the function app with the same storage account but with an updated task hub name. This results in the creation of new storage artifacts that can be used by the new version of your app. The old version of your app will continue to execute using the previous set of storage artifacts.

The issues doing it this way is:

1. It's up to you to figure out when it's safe to remove old versions.
2. It's not going to work if you use WaitForExternalEvent. If you have a flow where you receive an http request that triggers an on-going orchestration waiting for events, then you need to build some kind of router to pass events for old orchestrations to the right DF instance. You basically need a router in place for http requests and messages from mq's, and you're on your own to build this and figure out a way to pass it to the right instance.
3. The recommended approach by MS is to use deployment slots, but if you're on the consumption plan you only have 1 slot and can't deploy v3 before v1 is finished - but it does remove the burden of doing no. 1.

It's an inconvenience having to build something yourself that regularly checks for and removes old versions, and something I don't believe beginners of DF expects having to do, but no. 2 is a dealbreaker. Durable execution has a few but extremely powerful concepts. One of them is the ability to wait for external events. Because it's impossible to update such orchestrations without writing a complicated router yourself, your orchestrations can't ask a human for something or wait for callbacks/webhooks after it's started.

I wish problem no. 2 was made very clear in the documentation - that WaitForExternalEvent is going to make you suffer when you want to change something. But what I really want is for MS to fix this. I've tested a competing company's product for durable execution (not the one you think), and changes to orchestrations can indeed be made seamless for the user, including those that WaitForExternalEvents.