tkobayas commented on PR #6769:
URL:
https://github.com/apache/incubator-kie-drools/pull/6769#issuecomment-4766304893
```
[ERROR] AccumulateTest.testAccumulateMultipleFunctionsConstraint:1073 »
IllegalState Cannot transition to ACTIVE from REMOVED
[ERROR] AccumulateTest.testAccumulateMultipleFunctionsConstraint:1073 »
IllegalState Cannot transition to ACTIVE from REMOVED
[ERROR] AccumulateTest.testAccumulateWithFromChaining:784 » IllegalState
Cannot transition to ACTIVE from REMOVED
[ERROR] AccumulateTest.testAccumulateWithFromChaining:784 » IllegalState
Cannot transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testSimpleLengthWindow:1029 » IllegalState Cannot
transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testSimpleLengthWindow:1029 » IllegalState Cannot
transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testSimpleTimeWindow:973 » IllegalState Cannot
transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testSimpleTimeWindow:973 » IllegalState Cannot
transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testTimeAndLengthWindowConflict:2171 » IllegalState
Cannot transition to ACTIVE from REMOVED
[ERROR] CepEspTest.testTimeAndLengthWindowConflict:2171 » IllegalState
Cannot transition to ACTIVE from REMOVED
[ERROR] IncrementalCompilationTest.testUnchangedAccumulate:3723 »
IllegalState Cannot transition to ACTIVE from REMOVED
[ERROR] NamedConsequencesTest.testDynamicSalience:788 » IllegalState
Cannot transition to ACTIVE from REMOVED
[ERROR] NamedConsequencesTest.testDynamicSalience:788 » IllegalState
Cannot transition to ACTIVE from REMOVED
```
Unlinking happens UPSTREAM in the beta node, BEFORE the terminal node
processes the DELETE. The beta node (PhreakJoinNode, PhreakNotNode, etc.) calls
unlinkAndDeleteChildLeftTuple() which does
unlinkFromRightParent() + unlinkFromLeftParent() + stages as DELETE. By
the time PhreakRuleTerminalNode.doLeftDeletes runs, the tuple is already
disconnected from its parents.
So in the normal DELETE flow, the REMOVED tuple IS dereferenced — the
parent no longer holds it. This means the REMOVED→ACTIVE transition should NOT
happen through the normal parent-child path.
But there's an important exception: doLeftDelete can be called WITHOUT the
upstream unlink. This happens in:
- RuleTerminalNode.cancelMatch — calls doLeftDelete directly, no upstream
beta node involved
- PhreakBranchNode — calls doLeftDelete directly on branch tuples
- ActivationsManager.stageLeftTuple → transitionToActive via TMS
unblocking — the blocked tuple was never unlinked from its parent
In these paths, the tuple goes to REMOVED (or DORMANT) but stays linked to
its parent. A subsequent network re-evaluation at the parent node can find it
and propagate an UPDATE, leading to REMOVED→ACTIVE.
So the answer is: REMOVED tuples from the normal DELETE propagation are
fully unlinked and will be GC'd. REMOVED tuples from cancelMatch, branch node,
or TMS paths remain linked to their parents and can
legitimately be re-activated. That's why the failing tests (accumulate,
CEP windows, dynamic salience) hit REMOVED→ACTIVE — they use these non-standard
deletion paths.
---
Not yet clarifying the state transition use cases...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
