Bug 1329725 - [GSS](6.3.z)Node Hashing with type mismatch condition results in silent misfiring
Summary: [GSS](6.3.z)Node Hashing with type mismatch condition results in silent misfi...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: BRE
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Mario Fusco
QA Contact: Marek Winkler
URL:
Whiteboard:
Depends On: 1328380 1329771
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-22 17:55 UTC by Alessandro Lazarotti
Modified: 2020-03-27 19:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1328380
Environment:
Last Closed: 2020-03-27 19:13:34 UTC
Type: Bug


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.