Unfortunately Jint still chokes in this case if the expando contains
further nested expandos. It turns out that I need to do this
recursively for it to always work.
We also have trouble with IEnumerable types. They also can't be
round-tripped from/to JSON when they aren't deserialized as a very
specific type.
It appears that this can be fixed by intercepting occasions
when Jint returns an ExpandoObject but the desired return type
is simply object. In this scenario we must return
a Dictionary<string,object> instead of a simple object, or else
Jint freaks out should we try to stringify it later.
I also added a second test to prove that making this change hasn't
broken the way we expect Jint to work for us.
This is an experimental commit. It does stop the exception from
occurring, but it doesn't really fix the problem because now the
output is always empty-object.
It does prove that the exception was occurring because of the
usage of JsonConvert to serialize/deserialize the result.
The change made in this commit probably can't go into prod
but it is useful because it llustrates a part of the problem.
It looks like the docker credentials are incorrect, because
builds are failing with an auth problem. For example build 2.0.0-preview7.1704:
https://ci.appveyor.com/project/sfmskywalker/elsa/builds/38438996#L6715
This can be re-enabled once the auth issue is fixed. There should be
no real harm in disabling it, since it's not working at the moment anyway.
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.
