Is it possible to use Result objects in IPipelineBehaviourHandlers ?

[pillepalle1]

My project uses https://github.com/mcintyre321/OneOf (similar to Result objects) to avoid throwing exceptions. It works well with IRequest<OneOf<T, ProblemDetails>> and IRequestHandler<TRequest,OneOf<T,ProblemDetails>> , but now I am implementing validation via IPipelineBehaviour<TRequest, TResult> and want to return ProblemDetails if validation fails and next() if the validation succeeds. The problem here is that, even though TResult is guaranteed to be OneOf<T,ProblemDetails> for some T, the method Handle(...) has no way of knowing that and hence does not let me return objects the way I want.

I tried declaring it as public class ValidationBehaviour<TRequest,TResult> : IPipelineBehaviour<TRequest,OneOf<TResult,ProblemDetails>> but in that case the handler is not invoked, even though registered as services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehaviour<,>));

The same would go with some Result<T>. Is there a workaround for this issue or is there no way around throwing Exceptions ?

[pillepalle1]

I suppose a more generalised version of this question is: Is it possible to swap out the return object in an implementation of IPipelineBehaviour ? Since the handler is registered as an open generic IPipelineBehaviour<,>, there seems to not really a way to make assertion about TResult other in the where clause in the class declaration, which cannot be used, because then we don't have the inner type, ie.

public class MyBehaviour<TRequest,TResult> : IPipelineBehaviour<TRequest,TResult>
    where TRequest : IRequest<TResult>
    where TResult : OneOf<???,Problem>
{
    // Implementation goes here
}

The ??? denotes information that is missing. Is there a mechanism implemented to make this kind of assertion to the implementation?

If registered with concrete types, it works, but that is then pointless as there would be one handler registered for each Query or Command

services.AddTransient(typeof(IPipelineBehaviour<DevCmd,Oneof<Object,ProblemDetails>>), typeof(ValidationBehaviour<OneOf<Object,ProblemDetails>>);

[zprobinson]

I would like to add my voice here.

I'm trying to solve a very similar problem. We have the exact same setup with a Result<T, E> object.

We have a pipeline behavior that shoots off event messages on a message broker. This behavior is listening to something like 25~ events.

We found the same problem. Even if we were able to have some type of

   ///...
  where TResult : Result<T, Error>

we could pattern match on the inner value of the Result and do it that way.

We really don't want to define and implement 25+ specific implementations.

If you find a solution to this problem @pillepalle1 , I would love to hear what you came up with.

[pillepalle1]

I cannot say I found a solution but I made it work with inheritance and added the pipeline functionality to the GenerateResponseAsync below (as illustrated for logging and validation). It's not pretty but in practice fairly maintainable.

I switched to using OneOf instead of Result and I use a custom Problem object

public abstract class ARequest<TResponse> : IRequest<OneOf<TResponse,Problem>>
{
    internal Guid MediatorRequestId { init; get; } = Guid.NewGuid();
    public Guid GetRequestId() => MediatorRequestId;

    internal Stopwatch Stopwatch { init; get; } = new Stopwatch();
    public TimeSpan GetElapsedTime() => Stopwatch.Elapsed;
}

namespace Championpoker.Backoffice.Application.Cqrs.Common;

internal abstract class ARequestHandler<TRequest,TResponse> : IRequestHandler<TRequest,OneOf<TResponse, Problem>>
    where TRequest : ARequest<TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;
    private readonly ILogger<ARequestHandler<TRequest, TResponse>> _logger;

    public ARequestHandler(
        ILogger<ARequestHandler<TRequest,TResponse>> logger,
        IEnumerable<IValidator<TRequest>> validators)
    {
        _logger = logger;
        _validators = validators;
    }

    public abstract Task<OneOf<TResponse, Problem>> HandleImpl(TRequest request, CancellationToken cancellationToken);
    
    public async Task<OneOf<TResponse, Problem>> Handle(TRequest request, CancellationToken cancellationToken)
    {
        // TIME THE OPERATION
        request.Stopwatch.Restart();
        
        // ------------------------------------------------------------------------------------------------------------
        // PERFORM THE ACTUAL OPERATION
        var response = await GenerateResponseAsync(request, cancellationToken);
        await PostProcessResponseAsync(request, response, cancellationToken);
        // ------------------------------------------------------------------------------------------------------------
        
        // END TIMING
        request.Stopwatch.Stop();
        
        return response;
    }

    private async Task<OneOf<TResponse, Problem>> GenerateResponseAsync(TRequest request, CancellationToken cancellationToken)
    {
        // LOG INCOMING REQUESTS
        // This allows for tracing what happened in the past
        _logger.LogInformation("[Processing: {RequestId}] {Request}", request.MediatorRequestId, JsonSerializer.Serialize(request));
        
        // VALIDATE INCOMING REQUESTS
        // I am deeply agitated that this cannot be achieved through an IPipelineBehaviour, but apparently it is not
        // possible to use OneOf in IPipelineHandlers to return a Problem Instance there
        if (_validators.Any())
        {
            var context = new ValidationContext<TRequest>(request);

            var validationResults = await Task.WhenAll(_validators.Select(x => x.ValidateAsync(context, cancellationToken)));
            var failures = validationResults.Where(r => r.Errors.Any()).SelectMany(x => x.Errors).ToList();

            if (failures.Any()) 
                return Problem.RequestValidationFailed(failures.Select(x => x.ErrorMessage));
        }

        // WRAP LOGIC INTO TRY-CATCH
        // We do not want to expose Exceptions to the consumer. If an exception is thrown, it is converted to a Problem instance
        // and the user is informed about the failed request that way
        try
        {
            return await HandleImpl(request, cancellationToken);
        }
        catch (Exception e)
        {
            return Problem.ModelExceptionCaught(e);
        }
    }
    private async Task PostProcessResponseAsync(
        TRequest request,
        OneOf<TResponse, Problem> response,
        CancellationToken cancellationToken)
    {
        await Task.CompletedTask;
        
        // LOG REASONS FOR FAILED REQUESTS
        if (response.IsT1)
            _logger.LogWarning("[Failed: {RequestId}] {Response}", request.MediatorRequestId, JsonSerializer.Serialize(response.AsT1));
    }
}

And then each actual request looks similar to this:

public class LastUpdatedQuery : ARequest<DateTimeOffset>
{
    
}

internal class LastUpdatedQueryHandler : ARequestHandler<LastUpdatedQuery, DateTimeOffset>
{
    private readonly IApplicationDbContext _dbContext;

    public LastUpdatedQueryHandler(
        ILogger<ARequestHandler<LastUpdatedQuery, DateTimeOffset>> logger, 
        IEnumerable<IValidator<LastUpdatedQuery>> validators,
        IApplicationDbContext dbContext) 
        : base(logger, validators)
    {
        _dbContext = dbContext;
    }

    public override async Task<OneOf<DateTimeOffset, Problem>> HandleImpl(LastUpdatedQuery request, CancellationToken cancellationToken)
    {
        DateTimeOffset lastImported = await _dbContext.ActivitySummaries
            .Select(x => x.InclFrom)
            .OrderByDescending(x => x)
            .FirstOrDefaultAsync(cancellationToken);
        
        return lastImported;
    }
}