microsoft / RulesEngine / 26655296866

95%

master: 97%

push

github

Route ExecuteActionWorkflowAsync through RulesCache (fixes #471) (#734)

ExecuteActionWorkflowAsync previously called a private CompileRule(workflowName,
ruleName, ...) overload that always rebuilt the per-rule wrapper delegates from
scratch — no RulesCache lookup. With EvaluateRuleAction this turned every link
in a rule chain into a fresh compilation pass even when the workflow was
already registered.

This change routes the method through the same RegisterRule + GetCompiledRules
+ ApplyGlobalParams path that ExecuteAllRulesAsync uses. First call still
compiles; subsequent calls with the same workflow + param shape are cache hits.
Globals are evaluated once via the workflow-level cached delegate, matching
the existing #714 behavior.

Side cleanups:
- The now-unused private CompileRule(workflowName, ruleName, ruleParameters)
  overload is removed.
- EvaluateGlobalsAdHoc and CompileGlobalParamsDelegate are gone — the cache
  path supersedes them.

Benchmark (median of 5 runs, net8.0, 10-deep rule chain via EvaluateRuleAction):
  Chain x 100 invocations:     7 ms -> 3 ms   (~2.3x)
  Chain x 1,000 invocations:  65 ms -> 42 ms  (~1.5x)

The remaining time is delegate invocation + ActionContext setup; further wins
would need ActionContext JSON-serialization to be reworked, which is out of
scope here.

Also adds regression tests for both #471 and #513:
- Issue471Test verifies the cached path, chain correctness, and per-workflow
  cache-key isolation.
- Issue513Test documents the recommended OR-short-circuit pattern
  (NestedRuleExecutionMode.Performance under a single OrElse parent rule) for
  workflows that want "include if any rule matches" semantics.

All 160 unit tests pass on net6 / net8 / net9 / net10.

Co-authored-by: Yogesh Prajapati <yogeshcprajapati@outlook.com>

441 of 542 branches covered (81.37%)

10 of 10 new or added lines in 1 file covered. (100.0%)

817 of 854 relevant lines covered (95.67%)

631.46 hits per line