Support Custom Awaitable Types in Minimal API's

[justindbaur]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Currently custom awaitables are not supported and it is marked as a TODO in the code. Honestly, I don't have a use for this myself, I stick with Task and ValueTask but they exist out there and it would be nice to support them.

Describe the solution you'd like

Since a lot of work is done on this line to test whether the type is awaitable but the AwaitableInfo that method can return is discarded. I propose that information is used to create a custom Awaitable that also implements everything required to be an awaitable very similarly to ObjectMethodExecutorAwaitable. I believe there would be two versions of this. One with a void result and one non-void result. We can also utilize generics to create this object to minimize boxing. That awaitable is created using Expression.New and sent into a Execute[...] method so that we can await it.

One thing I propose this intentionally doesn't support is is the input delegate has a returnType of System.Object. Currently when objects have that return type it gets sent to this method. To support custom awaitables in that method we would have to utilize a lot of reflection each and every call and that would most likely slow down all the other Task<> and such calls so that it would be fine not supporting this for calls that have to go through the runtime to determine how to format their output.

Additional context

I have begun working on this but PR's require an issue to exist. I'm not quite ready to create a PR because I need to make sure it's fully tested but I am close.

[davidfowl]

I wouldn't add this until somebody asked for it. So we can leave this issue open and gauge interest. I'm pretty sure the importance of custom awaitable types will drop significantly because of ValueTask (it now supports extensiblity). So I'd rather no do this unless there was demand.

[justindbaur]

@davidfowl Totally understand. That's why I make it clear I don't even use it. Just wanted to play with Expressions and duck typing! But thought I would propose it anyways.

[davidfowl]

One thing I propose this intentionally doesn't support is is the input delegate has a returnType of System.Object. Currently when objects have that return type it gets sent to this method. To support custom awaitables in that method we would have to utilize a lot of reflection each and every call and that would most likely slow down all the other Task<> and such calls so that it would be fine not supporting this for calls that have to go through the runtime to determine how to format their output.

This is also why we didn't do it. Because we wanted parity with the object returning method, which is much more difficult to make efficient.

[justindbaur]

Yep, I did my initial work and then started adding tests for a CustomAwaitable return type to all the existing Theorys and immediately realized the work I had done wouldn't support object return type without doing a lot of reflection work, boxing, and casting in the runtime to get it to work. I'm happy with the other part of the work but as a user or minimal API's wouldn't want this code in ExecuteObjectReturn.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.