Please reconsider allowing async model validation

[JeremySkinner]

Suggestion

Hi, it would be great if the validation APIs could allow async model validation. This was previously suggested and closed in #7573, but it'd be greatly appreciated if you could reconsider.

Background information & context

I'm the author of the FluentValidaiton library, and we provide integration with ASP.NET's model validation API by implementing a custom ObjectModelValidator and ModelValidatorProvider. This works well for the most part, and is used extensively by the .NET community, however one sticking point is handling async validation.

FluentValidation's validators allow either sync or async execution, but because ASP.NET's validation APIs are only synchronous, we are unable to offer the library's full feature-set to ASP.NET users, and warn them that if their validator contains async code then it'll end up be run synchronously. If they need this to be async, they have to stop using auto validation and instead manually invoke the validator inside an async controller action. Neither of these are ideal.

Additionally, from an API design perspective we have to maintain 2 code paths inside FluentValidation for both the sync/async APIs which leads to a lot of duplication. This is mainly done for the sake of ASP.NET - if ASP.NET's validation pipeline was async, we could deprecate (and eventually drop) our synchronous implementation, but for as long as ASP.NET mandates synchronous validators we have to continue maintaining both implementations.

I believe the following types/methods would need to become async in order to support this:

• ObjectModelValidator.Validate overloads
• ValidationVisitor.Validate and the various methods called by this that recurse through the object graph
• IModelValidator.Validate and its implementors

(#7573 specifically asked for the data annotation attributes themselves to add async validation methods too, but personally I think this is less important. If the infrastructure were in place with the above types, then the community can provide async implementations of IModelValidator as necessary, whether that's using FluentValidation, or custom attributes or something else)

If you could reconsider adding support for this, it would be a very welcome addition for the users of our library. I'd be happy to help implement this, if that'd be valuable.

Please let me know if you need any more info.

Thanks for your consideration.

//cc @pranavkm

[javiercn]

@JeremySkinner thanks for contacting us.

We'll reconsider this and update the issue accordingly, however I can imagine already that one of the reasons we avoided this in the past is due to the perf implications involved in supporting async here.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[stevendarby]

Even if you decide again that you don’t plan to do this in the near future (the closing comment on the previous issue), would it be worth leaving the issue open so it can collect feedback from the community which might help you re-evaluate in future?

I remember coming across the closed issue soon after it was closed and have never been sure how long was appropriate to leave it before requesting it again.

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.

[sumtec]

Maybe the async validation will have a performance impact but it should be a choice for the end-user instead of forcing the user to write their own code to solve the problem with the async libraries.

Here is one of the scenarios:
The validation actually needs to check the value from the other underlying services which only provides an async method. This means we still have to either write the code to block the thread which is not quite sure if it will cause a deadlock in some cases. Or, we might need to write some codes to run that in another thread or similar which in the end will hurt the performance. This is not the worst. The worst is that it wastes a lot of time to check what is the right design when one side said that I have only async pattern and the other side said "No, I don't like it" while there are so many articles out there said that it will have a deadlock if you turn it into synchronous pattern incorrectly.

[jesslilly]

We use async code almost entirely. I have async code that I would like to use in one place and use again in a validator. But these limitations prevent me from doing this (cleanly).

This is not a bug in the framework, but it IS a big limitation.

Also @javiercn can you elaborate on the performance implications of async model validation? Couldn't this feature actually improve performance?