Support of async rules. Again :)

[valxv]

@snikolayev I've found a closed #84 issue labeled "wontfix". I've tried to implement the FireAsync() as you described and it was quite straightforward. BTW I haven't replaced Fire() with FireAsync() but implemented it in parallel.
So the question is why did you close this issue? Were there any hidden issues which I haven't faced yet, or it was just a decision to put it aside for a while?
Currently, we're investigating your project and potentially can collaborate :)

[snikolayev]

I decided not doing it not because it's hard or easy. I agree it is straightforward, but, running rules asynchronously makes assumptions about how the engine is used. For example, it assumes the rules either don't use the IContext, or synchronize their access to it. It also assumes that the app hosting the engine wants to use the thread pool for rules action execution, etc., etc.
I'm of an opinion that a framework should do few things, and do them well. It should also make as few assumptions about how it is used as possible.
So, I'm mostly seeing this capability as orthogonal to the rules engine domain.
I could be sold on someone writing an extension/integration library for NRules that adds that capability for those who need it. And if NRules is missing an extensibility point to do that, that I could consider as a valuable feature for the engine.
At the same time I don't want to be dismissive of requests like this, so LMK if this reasoning doesn't make sense or if I'm missing something.

[snikolayev]

And I'm looking forward to and would greatly appreciate collaboration on this project!

[ansongoldade]

Is there a way to do forward chaining asynchronously?

[snikolayev]

@ansongoldade no, forward chaining cannot be asynchronous

[adamhathcock]

I'm just finding this project (interesting stuff!) and simply changing all the methods (e.g. Rule methods and those that invoke them) to async wouldn't be feasible? It's not about running code in true parallel but chaining async from possible IO calls through the Rules engine. You shoudn't have to change much other than adding await commands :)

I might want to do things like retrieve and save data from a DB inside a rule. Just thinking how it would play out.

[adamhathcock]

Having played around further and trying to discover the best practices, maybe having IO type logic is considered an anti-pattern with this library?

I’ve written some of my logic without IO in the rules but that requires gathering a lot of context upfront.

I plan on attempting to make a PR for async usage. Still learning this library. Thanks again for it!

[adamhathcock]

Finally started looking at it. Quickly ran into Expression issues which I know next to nothing about expression trees.

In my own usage, I've generally solved issues by first gathering all context, use a rules session, then inspect the results instead of trying to use EFCore or something inside the rules. Maybe this is the intended best practice? Avoid IO altogether in a rule?

[snikolayev]

@adamhathcock yes, that's exactly my thinking - avoid IO inside the rules actions.

[mohammad1111]

The rules in my system mostly use IO. Having async helps me a lot, do you have a plan to add it? If not, can you guide me how to add this feature to the source?