Bug 1329725

Summary: [GSS](6.3.z)Node Hashing with type mismatch condition results in silent misfiring
Product: [Retired] JBoss BRMS Platform 6 Reporter: Alessandro Lazarotti <alazarot>
Component: BREAssignee: Mario Fusco <mfusco>
Status: CLOSED EOL QA Contact: Marek Winkler <mwinkler>
Severity: high Docs Contact:
Priority: high    
Version: 6.2.0CC: etirelli, hmiura, mfusco, mwinkler, tkobayas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1328380 Environment:
Last Closed: 2020-03-27 19:13:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1328380, 1329771    
Bug Blocks:    

Description Alessandro Lazarotti 2016-04-22 17:55:06 UTC
+++ This bug was initially created as a clone of Bug #1328380 +++

Description of problem:

If you have 2 rules with type mismatch condition (Person.status is String),

=====
rule "rule1"
    when
        Person(status == 1)
    then
        System.out.println( "rule1" );
end

rule "rule2"
    when
        Person(status == 2)
    then
        System.out.println( "rule2" );
end
=====

Person with status "1" hits "rule1" thanks to Mvel coercion.

=====
Person p = new Person();
p.setStatus("1");
kSession.insert(p);
kSession.fireAllRules();
=====

However, if you have 3 rules,

=====
rule "rule1"
    when
        Person(status == 1)
    then
        System.out.println( "rule1" );
end

rule "rule2"
    when
        Person(status == 2)
    then
        System.out.println( "rule2" );
end

rule "rule3"
    when
        Person(status == 3)
    then
        System.out.println( "rule3" );
end
=====

Person with status "1" doesn't hit "rule1".


Steps to Reproduce:
1. I'm going to send a test case PR.

Actual results:

"rule1" is not fired.

Expected results:

"rule1" is fired

or

give an error or warning.

--- Additional comment from JBoss Product and Program Management on 2016-04-19 05:10:19 EDT ---

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Toshiya Kobayashi on 2016-04-19 05:17:47 EDT ---

Sent a test case PR:
https://github.com/droolsjbpm/drools/pull/745

--- Additional comment from Mario Fusco on 2016-04-20 09:26:28 EDT ---

Fixed by https://github.com/droolsjbpm/drools/compare/5801072...434c6e2

--- Additional comment from Edson Tirelli on 2016-04-21 13:36:51 EDT ---

Mario, if this is fixed, can this ticket be set to MODIFIED? Which branches was the fix committed to?

--- Additional comment from Mario Fusco on 2016-04-22 02:41:17 EDT ---

Edson, I haven't flagged this ticket as MODIFIED since I've pushed the fix only on master. Please let me know if I'm allowed to cherry-pick it to branch 6.4.x.

Comment 2 Mario Fusco 2016-04-26 08:59:30 UTC
Cherry-picked to branch 6.4.x with https://github.com/droolsjbpm/drools/compare/d2391b0...58ddfd1