Daniel Gerlag

We could implement that, but we'd need to do it for every persistence provider, there are 8 of them :)

@ling921 thanks for the effort. Unfortunately, this does not make sense to wrap an entire workflow in a scope. When the workflow is executed, the entire thing "may" be executed...

Why don't you just map the compress output to a value on the workflow data object and then map to input of the next step to that field?

You could create an alternative implementation of `IWorkflowRegistry` that persists to a datastore and swap it out with the in-memory one.

The `Branch` is not a switch case. It will select all matching branches and schedule them to run in parallel, this is by design... you would need to be more...

By picking a single branch, it would imply that the order in which the branches are defined would affect the outcome... not sure I'd be comfortable with that ambiguity. What...

Thanks for discovering that. We should not set the BodyType to null in the EndStep, that would be the correct solution.

> what should be the body type then? typeof(EndStep).Name

Interesting observations! I think we'd need to do some testing around how spikes of new workflow affect performance, the locking mechanism sounds like a prime suspect.

I don't think this is a .NET 7 issue... you should be able to use .NET 7 with EF Core 6.... It is an EF Core issue, the culture of...