How to resolve a custom step name when I use a generic workflow step type?

[cervengoc]

I've implemented my workflow steps as the following.
I have a generic workflow step type, like this:

public class GenericWorkflowStep<THandler, TInput, TOutput> : StepBodyAsync
{
   ...
}

Each of my actual step handlers look something like this:

public class MyStepHandler
{
    public async Task<MyStepOutput> Execute(MyStepInput input, CancellationToken ct)
    {
        ...
    }
}

In the generic workflow step I dynamically resolve a handler instance, and call its Execute method by convention, etc.
The point with this design is to have loosly coupled handlers for our workflows, which by themselves do not depend on WFC in any manner.

However, at the moment WFC resolves the name of a step using the type name, so every step will become "GenericWorkflowStep``1", which definitely cause some UI and listing related issues on our side, but may cause some unwanted effects on WFC side as well.

I'm aware that I can pass an explicit step name when building the workflows. However, we have many workflows, using many shared steps, so that would be a huge and error-prone work (eg. what if a developer misses it somewhere).

What is the best way to implement some kind of centralized logic to resolve the step name in a custom way, for example in this case using the third generic type argument of the step type?

[cervengoc]

In addition, I started to "play" with inheriting from WorkflowBuilder and WorkflowBuilder<TData>, and override the Build method so that for each step which has this generic type, the step names are "fixed" from step.BodyType.

However, I struggle to get it work, as the UseData<TData> method of the non-generic WorkflowBuilder is not virtual, hence always instantiating the default WorkflowBuilder<TData> type.

Of course there would probably be the obvious chance to decorate the IWorkflowBuilder and IWorkflowBuilder<T> interfaces with this extended implementation, however, that does not seem to be very clean as two dozens of methods must be implemented/redirected to the wrapped instance.