CommandPreHandler generic <Request, Response>

[josealmir]

Hi People ...

I'm starting to use Litebus; it's a very good package, but when implementing it in my project, I noticed that it doesn't have a generic CommandPreHandler for TRequest and TResponse.
Currently, we don't have a way to implement a generic pipeline of that type.
Do you have plans to implement either of these types ?

[litenova]

Hi there! Thanks for trying out LiteBus.

You actually don't need a generic ICommandPreHandler<TRequest, TResponse> to implement a generic pipeline. LiteBus handles this differently and arguably more flexibly through Polymorphic Dispatch and by strictly separating "Pre" (before execution) and "Post" (after execution) concerns.

Here is how you can achieve your goal and why this design is chosen over the MediatR style.

1. The Solution: Polymorphic Dispatch

In LiteBus, handler interfaces are contravariant (defined as in T). This means a handler defined for a base type (or interface) will automatically handle all messages that derive from that type.

If you want a "Global" pipeline that runs for every command, you have two ways to define it.

Option A: The Non-Generic Shortcut

You can implement the non-generic ICommandPreHandler, which is designed specifically for global command logic.

using LiteBus.Commands.Abstractions;

// This runs for ALL commands in the system.
public class GlobalLoggingPreHandler : ICommandPreHandler
{
    private readonly ILogger<GlobalLoggingPreHandler> _logger;

    public GlobalLoggingPreHandler(ILogger<GlobalLoggingPreHandler> logger)
    {
        _logger = logger;
    }

    public Task PreHandleAsync(ICommand command, CancellationToken cancellationToken = default)
    {
        _logger.LogInformation("Global PreHandler executing for: {CommandType}", command.GetType().Name);
        return Task.CompletedTask;
    }
}

Option B: The Generic Base Type (Polymorphic)

You can also explicitly implement ICommandPreHandler<T> where T is ICommand. This demonstrates the underlying mechanism: because every command implements ICommand, this handler matches everything.

// This is functionally equivalent to Option A.
// It demonstrates that you can target any base type or interface.
public class GlobalLoggingPreHandler : ICommandPreHandler<ICommand>
{
    public Task PreHandleAsync(ICommand command, CancellationToken cancellationToken = default)
    {
        // Logic here...
        return Task.CompletedTask;
    }
}

2. Why no TResponse in PreHandlers?

In the MediatR "Pipeline Behavior" pattern, you wrap the entire execution, so you have access to both the Request (before) and the Response (after next()).

LiteBus separates these concerns to adhere strictly to the Single Responsibility Principle:

• PreHandlers run before the main handler. At this stage, the result does not exist yet, so TResponse is irrelevant.
• PostHandlers run after the main handler. If you need to inspect or modify the result, you use ICommandPostHandler<TCommand, TResult>.

If you need to share state between a PreHandler and a PostHandler (e.g., a stopwatch for performance timing), you can use the AmbientExecutionContext.

3. Why is this more powerful than MediatR?

While MediatR's IPipelineBehavior<TRequest, TResponse> is a "catch-all" wrapper, LiteBus's polymorphic approach allows for much more granular and semantic control over your pipeline without complex generic constraints.

Instead of a global behavior that runs for everything (and requires if statements inside to filter), you can define pipelines based on what the command is (via interfaces).

Example: Targeted Pipelines

Imagine you have an interface ISecuredCommand:

public interface ISecuredCommand : ICommand 
{
    string RequiredRole { get; }
}

You can write a single PreHandler that only runs for commands implementing ISecuredCommand:

// This automatically runs ONLY for commands implementing ISecuredCommand.
// It will NOT run for public commands that don't implement it.
public class SecurityPreHandler : ICommandPreHandler<ISecuredCommand>
{
    public Task PreHandleAsync(ISecuredCommand command, CancellationToken cancellationToken)
    {
        // Check permissions using command.RequiredRole
        return Task.CompletedTask;
    }
}

[josealmir]

Hi @litenova ,Thank you for your explanation. My point is that I need to abort the handle execution when a command is invalid, without having to implement multiple validation handles or throw Exception.
I am implementation like this:

public sealed class ValidatorCommandPreHandler(
    ILogger<ValidatorCommandPreHandler> logger,
    IServiceProvider serviceProvider) : 
    ICommandPreHandler<ICommand>
{
    public async Task PreHandleAsync(ICommand request, CancellationToken cancellationToken = new CancellationToken())
    {
         // validation here
         if (isValid)
             throw  new ValidationException(result.Errors)
    }
}

I'm catching the error here to

public sealed class ErrorCommandHandler(ILogger<ErrorCommandHandler> logger): ICommandErrorHandler<ICommand>
{
    public Task HandleErrorAsync(ICommand message, 
        object? messageResult, 
        Exception exception,
        CancellationToken cancellationToken = new CancellationToken())
    {
        using (logger.BeginScope(new Dictionary<string, object> { { "Command", message } }))
        { 
            AmbientExecutionContext.Current.MessageResult = (Result.Error(exception));
            // return exception is ValidationException ? Task.FromResult(Result.Error(exception)) : Task.CompletedTask;
            return Task.CompletedTask;
        }
    }
}

In this ErrorCommandHandler existes possible
change return.

[litenova]

Hi @josealmir,

We actually already have a built-in mechanism for this via the Execution Context. You don't need to throw an exception and catch it in an error handler; you can simply Abort the pipeline directly from your PreHandler.

1. Using Abort instead of Exceptions

You can use AmbientExecutionContext.Current.Abort(). If your command expects a return value (e.g., ICommand<Result>), you can pass that result directly to the Abort method.

Here is how you can refactor your ValidatorCommandPreHandler:

public sealed class ValidatorCommandPreHandler(
    ILogger<ValidatorCommandPreHandler> logger,
    IServiceProvider serviceProvider) : 
    ICommandPreHandler<ICommand>
{
    public async Task PreHandleAsync(ICommand request, CancellationToken cancellationToken)
    {
         // 1. Perform validation
         var validationResult = Validate(request);

         if (!validationResult.IsValid)
         {
             // 2. Log the issue if needed
             logger.LogWarning("Validation failed for {CommandType}", request.GetType().Name);

             // 3. Abort execution immediately and return the error result.
             // The pipeline stops here. The Main Handler and Post Handlers will NOT run.
             AmbientExecutionContext.Current.Abort(Result.Error(validationResult.Errors));
         }
         
         // If valid, do nothing. The pipeline continues automatically.
    }
}

Note on Return Types: When using Abort(value), ensure that the value you pass matches the return type defined by the command (e.g., if the command is ICommand<Result>, you must pass a Result object).

You can read more about this feature in the documentation here:
👉 Execution Context: Aborting Execution

2. Future Plans regarding Result Objects

Regarding your usage of Result.Error(...): First-class support for a standard "Result Pattern" (monads) is actually something I have in mind for a future version of LiteBus. For now, the approach above using your own Result class combined with Abort is the recommended way to handle this scenario.

Hope this helps!

[josealmir]

Hi @litenova, I finished implementing LiteBus in the project exactly as I had envisioned. Here's the project link to access: https://github.com/josealmir/notredame.
Thanks for the help.

[litenova]

Hi @josealmir,

Sorry for getting back to you late,
I looked your implementation in notredame and everything looks good. I have one suggestion; You can use ICommandValidator instead of ICommandPreHandler<ICommand>, it provides better semantic declaration.