Passing arguments to next in pipeline behaviors

Currently, the next parameter in IPipelineBehavior<TRequest, TResponse>.Handle is a RequestHandlerDelegate<TResponse> which takes no argument.

This is a problem, because it means it’s impossible for a behavior to pass anything other than the original request to the next behavior.

Here are two examples where it could be useful to be able to do that:

• Applying a transformation to the request before it’s passed to the rest of the pipeline. It’s possible to modify the current one, but that works only if the request is mutable.
• Passing a different cancellation token. For instance, I’d like to pass HttpContext.RequestAborted if no cancellation token was passed explicitly.

I realize this would be a breaking change, but maybe in a future major version?

[lilasquared]

Of course, you could introduce a new interface for behaviors, but it would probably make things confusing…

yeah this is what I was thinking but I can see how it would get cumbersome.

This has been discussed before in a few other issues as well I think, here is one with a response from the author https://github.com/jbogard/MediatR/issues/361

A mutable dependency on both the pipeline(s) and the handler seems to be the suggested approach.

[thomaslevesque]

Hi @lilasquared,

It wouldn’t necessarily be a breaking change if the library continued to support calling the delegate with no args.

How would you do that? The interface has to change anyway. RequestHandlerDelegate<TResponse> would need an additional TRequest generic type parameter, so it would no longer be the same type, so existing implementations would be broken.

Of course, you could introduce a new interface for behaviors, but it would probably make things confusing…

or is it more the principle of having immutable requests?

Yes, that. My requests are often immutable.

For your second, I remember a conversation about cancellation token in another issue…#496 the solution here was to wire up a new mediator that used the request aborted cancellation token if none was provided.

Yes, I thought of doing this too. It’s not a big deal, but I thought a behavior would be a really good fit for this, so I was a little disappointed when I realized it wasn’t possible.

Actually, since the handlers and behaviors are bound by type to the requests themselves, the “transformation” you’re talking about would have to transform it to the same request type anyway

Yes, I’m aware of this limitation.