Feature: Activity Error/Fault Handling

Hi @sfmskywalker,

Has any thought been put into handling errors/faults?

Could the “ActivityBase” class define a outcome of “Faulted” as standard, or change the below to always add OutcomeNames.Fault to the list.

public static ActivityDescriptor Describe(Type activityType)
        {
            var activityDefinitionAttribute = activityType.GetCustomAttribute<ActivityDefinitionAttribute>();
            var typeName = activityDefinitionAttribute?.Type ?? activityType.Name;
            
            var displayName =
                activityDefinitionAttribute?.DisplayName ??
                activityType.Name.Humanize(LetterCasing.Title);
            
            var description = activityDefinitionAttribute?.Description;
            var runtimeDescription = activityDefinitionAttribute?.RuntimeDescription;
            var category = activityDefinitionAttribute?.Category ?? "Miscellaneous";
            var icon = activityDefinitionAttribute?.Icon;
            var outcomes = activityDefinitionAttribute?.Outcomes ?? new[] { OutcomeNames.Done };

           //Insert OutcomeNames.Faulted into the list here

            var properties = DescribeProperties(activityType);

            return new ActivityDescriptor
            {
                Type = typeName.Pascalize(),
                DisplayName = displayName,
                Description = description,
                RuntimeDescription = runtimeDescription,
                Category = category,
                Icon = icon,
                Properties = properties.ToArray(),
                Outcomes = outcomes
            };
        }

If execution faulted, and the workflow has a connection for the “Faulted” outcome, follow its path to another activity and schedule it. If there is no connection, just fault the workflow as normal.

The next activity could just go back some steps and try the set of steps again (it could also do this a set number of times), or it could do a rollback to perform a clean up, then exit as faulted.

It could even point back to itself, to perform a retry with a TimedEvent activity.

Hopefully the above makes sense to you.

Thanks

[terry-delph]

I am hesitant however to have every activity expose a Faulted outcome, because there are activities that are not expected to fault, like WriteLine and SetVariable (if they were to fault, that would be either a bug in the activity or some off-chance fluke where the host is crashing or something like that). I don’t want to unnecessarily “clutter” the activity designer just because in theory there’s a minute chance that any line of execution could fail.

That is well justified for specifically stating it can Fault rather than always. Alternatively, the IActivity interface could have a boolean “CanFault” property that can be used for that purpose. If true, automatically add the Faulted outcome.

When the workflow invoker executes the activity, and the activity throws an exception, the workflow invoker checks if the activity exposes a “Faulted” outcome. If so, any connected activity to that outcome will be scheduled next, using he exception as an input for that activity.

Love the sound of that.

Alternatively, or maybe additionally, an activity could implement a “HandleFault” method. The activity can return any ActivityExecutionResult it wants. Perhaps even a RetryResult to implement some kind of error policy.

Love this also, and makes the activity more configurable for different scenarios of transient errors.

Some more food for thought, not immediately relevant: In a future version, I am thinking about container activities, like ForEach, Sequence, While, etc. but also maybe a Try activity. Any activity faulting in that container would trigger the “Faulted” outcome of the “Try” activity.

This would be great for grouping activities that need to be executed together after a failure and then retrying. If will also be more visually pleasant and easier to understand if the designer houses them in a container too.

[sfmskywalker]

I agree, let’s not have a general Try/Catch activity to catch any and all exceptions, but instead let individual activities decide what to handle and how to expose outcomes (the HTTP Request activity is a great example).