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.
As stated in the comments for
WorkflowMayContainDuplicateActivitiesIntegrationTests
These tests might not describe actually-desired behaviour.
If they begin to "get in the way" in future, then it would
probably be safe to remove them.
As well as providing a unit test which matches other persistence
provider tests (round-tripping a workflow instance), two other tests
are included here:
* When using the default DI registration extension method, this sets
up pooling of DB contexts and so a resolved context will come from
the pool.
* When using the non-pooled DI registration extension method, this
sets up EF without pooling, which is more useful in a multi-tenanted
environment.
There are also some other changes in this commit corresponding to
improving the tests. Mainly de-duplicating logic & improving names.
This adds new elective functionality to EF Core persistence:
* Use non-pooled DB Contexts
* Allow control of (non pooled) DB Contexts service lifetimes
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.
This test case shows that in-memory persistence is
also affected. It seems that that would mean that this
issue is not related to only a single persistence provider.
In fact, in retrospect this is not really a persistence
problem at all, but a problem with the test case. More
information is available in the comments to #728.
This brings some of the tests I was writing for #552 into
this branch. That's where I first repro'd this problem and
I will begin my work based on that.
