I have not checked but does the short circuiting actually work? The goal of it is to lower the resource usage of the tool. If it continues to run and generate longer than we have a problem still.
On Sun, Dec 4, 2022, 08:50 Henrik K <h...@hege.li> wrote: > > Fixed simply with some rule changes as described in the bug. > > > On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now open on > this > > issue. > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Tue, Nov 29, 2022 at 1:11 PM <giova...@paclan.it> wrote: > > > > On 11/28/22 17:47, Bill Cole wrote: > > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 > -0500) > > > Alex <mysqlstud...@gmail.com> > > > is rumored to have said: > > > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > > kmcgr...@apache.org> > > >> wrote: > > > [...] > > >>> Also, would be helpful to know if this is different than 3.4.6's > > behavior. > > >>> > > >> > > >> Oh yes, I meant to mention that it is different behavior for > 3.4.6. Same > > >> score for the rule, but it appears to actually shortcircuits the > > processing > > >> of additional rules. At the least, it doesn't add those MISSING_* > rules. > > > > > > This is almost certainly a side-effect of recent reworking of the > > housekeeping around which rules have been run. > > > > > > As a temporary work-around, I think it would be wise to give any > rule > > that gets SHORTCIRCUITed an overwhelming score in whichever > direction it > > operates. > > > > > > > > Confirmed, r1904981 is the commit that is causing this behavior. > > Giovanni > > >
