Formal support for the stupid Result pattern in "Wolverine as MediatR" usage

[jeremydmiller]

It comes up a lot, and I'm feeling like you almost can't fight it off. Make it easy for the Wolverine "Railway Programming" model to be usable with the stupid Result<T> thing. Maybe automatically map the real message w/ Result on success. Try to get this done w/o the stupid high ceremony code that people using MediatR love in LinkedIn posts on "Exceptions bad, clumsy Result good" posts

[nkosi23]

I just hope it'll be opt-in (or at least transparent) for users not interested in dealing with Result.

[dmytro-pryvedeniuk]

@jeremydmiller You used "stupid" word twice. Where is old good "it depends"? :) IMO it should be up to developers how to implement their API: throw an exception or return "failed" result. Both work as long as the contract is clear for the callers.
On the other hand why should Wolverine care? In the example below Wolverine is used with OneOf result. Is something else meant in the request?

public record CompleteTask(TaskId Id);

public static class CompleteTaskHandler
{
  public static async ValueTask<Domain.Task?> LoadAsync(
    CompleteTask command, ITaskRepository taskRepository, CancellationToken ct)
  {
    return await taskRepository.GetByIdAsync(command.Id.Value, ct);
  }

  public static IEnumerable<object> Handle(CompleteTask command, Domain.Task? task)
  {
    if (task is null)
      return [new NotFound()];

    var result = task.Complete(DateTimeOffset.UtcNow);

    return result.Match<object[]>(
      success => [
        new Success(), // Result A
        new TaskCompleted(command.Id)], // Event A
      alreadyCompleted => [
        new TaskIsAlreadyCompleted(), // Result B
        new TaskFailedToComplete(command.Id, "Already completed")] // Event B
    );
  }
}

[GenerateOneOf]
public partial class CompleteTaskResult : OneOfBase<Success, NotFound, TaskIsAlreadyCompleted> { }

[jeremydmiller]

@nkosi23 100% optional, and honestly, what I want is something that will wrap the Result stuff for you outside your handler so your handler code can remain as simple as possible.

@dmytro-pryvedeniuk Remember the the whole Wolverine schtick is to reduce code ceremony, and custom Result types are code ceremony. Code ceremony that's only necessary if you go down the silly "Wolverine as MediatR" strategy instead of Wolverine.HTTP where you can write cleaner code with our railway programming support and neither use silly Result types nor have to throw exceptions. Even in your code, the Result stuff is really only necessary when you're doing some layering between the data access and the behavioral code. In idiomatic Wolverine, you'd skip the repository wrappers altogether so you don't have to worry about the Result type stuff.

The only real exception I see is for users who are using Hot Chocolate or something similar where the best you actually can do is Wolverine as MediatR under their mutation model and that's honestly the use case that spawned this item because a JasperFx client is wanting to do just that.

And sorry, I can't even begin to tell you how much I detest the type of code you just pasted here! To each their own though:-)

[donniehale-awh]

I can boil down my interest in this topic to the following.

// If I use InvokeAsync and expect a return value
var response = bus.InvokeAsync<ResponseType>(message);

// And if in a handler's "Before" method (or equivalent), I have this code:
return (HandlerContinuation.Stop, new ResponseType());

// Go ahead and return that ResponseType instance to the caller of InvokeAsync

Yes, my use case is a very simple MessageResponse record type. It's not the full-blown kind of thing Andrew Lock works through in this series: https://andrewlock.net/series/working-with-the-result-pattern/ (where he does refer to @jeremydmiller). But as I see it, that's corollary to the main point of allowing a stopped message handler to return a response.

[nkosi23]

@donniehale-awh All I'm going to say regarding the series you have linked to is that I use F# as a daily driver and we essentially have native support for Result[T]. However, even Microsoft employees actively involved in designing the language recommend just throwing exception.

Otherwise be prepared to learn the hard way that all attempts to use the result pattern for control flow end up reinventing the stacktrace (a poor man's version of the stacktrace). It is the kind of thing that may only be useful in any surface of your system (like 0.1%) if ever, and this surface will almost never be located at the boundaries of your system but rather in the core domain model.

And when folks say that exceptions are slow, let's not forget that they still only take a couple of microseconds. By contrast, a single database query / network hop takes a couple of milliseconds. I'll stop here as i do not want to hijack this thread.

[donniehale-awh]

I appreciate your reply. I'm not trying to do anything like that. Some premises in what I'm doing:

1. There's a meaningful distinction between an event's entry point such as an http request handler and the entire call stack of business logic required to implement a handler.

2. The only code consuming a "Result" are minimal API endpoints. They're not being passed through the entire call stack of business logic.

3. Irrespective of what type is returned to the endpoint, some control flow code will be involved to determine, for example, what HTTP status code to return.

So from my POV, Wolverine couldn't care less that someone is using what I'm asking for to do "Result" or to just return a DTO via HandlerContinuation.Stop because Before did everything that was needed.

I'm probably oversimplifying the implications for Wolverine in my head, but I'm definitely not suggesting that InvokeAsync's signature needs to change to allow for 2 different possible response types.

P.S. If anything in my tone starts to sound like I'm ready for a religious war, please let me know.

[jeremydmiller]

@donniehale-awh You are "oversimplifying the implications for Wolverine in your head" here:) We have to teach Wolverine about the special result types so that it can use that as an early exit and/or wrap the desired output.

[donniehale-awh]

@jeremydmiller I'm probably not being sufficiently clear in what I'm requesting / suggesting. What I am trying to suggest is that it's up to the user of Wolverine to deal with the type returned to InvokeAsync<MyResponseType>. The handler code must return a MyResponseType whether HandlerContinuation.Stop short-circuits the handling or whether the handler returns normally.

So a developer using Wolverine may specify a return type of a List<MyDto> and if the handler needs to short circuit, it returns (HandlerContinuation.Stop, []). In this case, the response type doesn't have anything to do with the controversy discussed above. It just lets the caller know he/she should never get back a null response.

If that was already clear and your comment about teaching Wolverine about special result types still stands, then I'm definitely oversimplifying.

[jeremydmiller]

@donniehale-awh That's actually kind of the easy part. There's some real work in the Wolverine side to understand that a custom result type means "stop". You still have to publish that stupid Result type to the caller for the "nothing here" case.

[donniehale-awh]

@jeremydmiller Just in case we're talking past each other, what I would expect (or at least want) is not that a custom result type means "stop" but that HandlerContinuation.Stop would mean "stop and return this object to the InvokeAsync caller". Maybe that's what you're saying, but in case anything is being lost in translation. Thanks for the reply.

[jeremydmiller]

@donniehale-awh More or less, but I'd like you to just be able to return whatever that type is instead of the awkward (HandlerContinuation, MyResult?) response. Usability matters here:)