It seems that some work done in these commits, for the
file ForEachBuilderExtensions was responsible:
* 4807ace13c
* dfbba1e176
A couple of the extension methods were missing out a ToList()
which later caused an ArgumentException when setting a property
value via reflection.
I also added an extra exception for the set-value logic. This way,
if/when there is a problem, the exception will indicate which property
it was trying to set at the time.
This replaces the `Then(string activityName)` method with `ThenNamed(string activityName)`.
A new method is added to allow connecting to activities by type name: `ThenTypeNamed(string activityTypeName)`.
The reason for this change and addition is to allow workflow builders to connect to activity types that do not have a corresponding type.
For example, the Telnyx project has an activity type provider that *dynamically* provides activity types based on Telnyx webhook callback types.
One of these tests is failing and this is the one which
demonstrates issue #738. The composite activity which begins
with ReceiveSignal doesn't generate a trigger.
This extension method is quite complex and is frustrating
when a unit test passes-through it. That's because extension
methods can't be mocked in tests.
This is pretty trivial really, it just cuts down on
indentation and moves the looping into a Linq
map (Select) which builds a collection and then
reduces it (SelectMany) to a flattened collection.
Also remove some needless await'ing.
The triggers-for-activity-blueprint functionality
is quite complex just on its own, so I have moved this to
a new service.
Once again the integration test which is left behind proves
that it still does the same job.
This reworks the way that the default behavior is selected, in line
with comments. The changes to the enum are reverted, and the
three places which create a workflow definition are now altered to
explicitly choose WorkflowBurst
This includes a change to the TS enum definition - update to match
its C# counterpart.
This also includes a change to the workflow used in the test-case.
There are quite complex reasons for this, as explained here:
https://github.com/elsa-workflows/elsa-core/issues/728#issuecomment-794319236
The real crux of it is that the workflow must have an activity
which suspends it, and that activity that suspends the workflow
must not be the starting activity. This is why I added an unused
set-variable activity as the starter.
This commit shows that the various persistence test cases _mostly_
work OK, with the one exception of ActivityExecuted.
