Fix: Prevent nil pointer dereference when reporting rule evaluation errors

[rohitss912]

Problem

When a rule contains an invalid function/field(s) in its [when] expression, the engine logs the error but then panics with a nil pointer dereference.
This happens because the error reporting (Line 186) :

fmt.Errorf("evaluating expression in rule '%s' the when raised an error. got %v", dataContext.GetRuleEntry().RuleName, err)

tries to access dataContext.GetRuleEntry().RuleName before SetRuleEntry is called in engine.go, resulting in a nil pointer dereference.

How to Reproduce

Use a rule with an invalid function in the [when] clause, for example:

rule BadRule "Rule with invalid function" {
    when
        MyApp.IsProduction == false && MyApp.PlatformType.IsIn("DataCenterEU")
    then
        // some action
}

Here, IsIn is not a valid function for a string in Grule.

Observed Behavior

The AST logger prints the actual error (Line 184):

caller":"ast/RuleEntry.go:184","message":"Error while evaluating rule BadRule, got right hand expression error.  got this node identified as \"MyApp.PlatformType\" call function IsIn is not supported for string"

But instead of returning this error to the caller, the engine panics and returns the below error message which could be misleading to the caller of the rule-engine :

 Got error error while evaluating rule BadRule ! recovered : runtime error: invalid memory address or nil pointer dereference

Solution

Change the error reporting to use the current RuleEntry's e.RuleName directly, rather than accessing it via dataContext.GetRuleEntry(), as the code anyway uses e.RuleName to prepare the AST logger error message.

This ensures error messages are constructed safely, even if the rule's name has not yet been set in the data context.

Code Fix

Before:

return false, fmt.Errorf("evaluating expression in rule '%s' the when raised an error. got %v", dataContext.GetRuleEntry().RuleName, err)

After:

return false, fmt.Errorf("evaluating expression in rule '%s' the when raised an error. got %v", e.RuleName, err)

Impact

Prevents engine panics when evaluating rules with invalid syntax.
Ensures errors are returned to the caller as expected.
No impact on valid rule execution or rule selection logic

[rohitss912]

@newm4n hey could you please take a look at this ☝🏾

[newm4n]

This is correct, when you know that the rule not exist, there's no reason to get the rule name using the non-existent rule. Thats silly.