drccrd opened a new pull request, #7119: URL: https://github.com/apache/incubator-kie/pull/7119
Follow-up to the review on #7110, which asked for the remove-rule path and for an accumulate over a subnetwork source. Removing a rule renumbers the position bits of the merged memory prototypes through SegmentPrototype.mergeProtos(), with the same MemoryPrototype.setNodePosMaskBit() calls that splitProtos() uses. Removing the rule that caused the split is not enough to reproduce the bug: the numbering is positional, so un-splitting a segment restores exactly the build-time bits that the stale wrapped BetaMemoryPrototype still holds. A live session does not reproduce it either, because EagerPhreakBuilder.mergeSegment() pushes the bits of the prototypes into the existing memories rather than populating them from the prototypes. The accumulate node therefore has to end up at a different position than the one its prototype was built with, which needs the splitting node and the merging node to be different ones, and the session has to be created after the removal. Added that case plus its live-session counterpart and the straightforward removals of the rule that split the segment. An accumulate whose source is a subnetwork always roots its own segment: the subnetwork branches off the left tuple source of the accumulate node, which gives that source more than one sink and makes it a segment tip, so neither a split nor a merge can renumber the node. The added tests pin that invariant down, since it is the reason the bug cannot reach such a node, and they cover the branch of BetaMemoryPrototype.populateMemory() that resolves the SubnetworkPathMemory of the wrapped TupleToObjectNode. Verified against drools-core with and without the fix: 34 runs pass with it, 8 fail without it, including the new accumulateBehindAJoinFiresInASessionCreatedAfterTheSplittingRuleIsRemoved. -- 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]
