https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8116
--- Comment #4 from Henrik Krohns <apache@hege.li> ---
(In reply to Andreas Erhard from comment #3)
> Thanks for showing a possible workaround.
>
> I do understand your argumentation, but to me it sounds wrong, that you
> can't call got_hit() on PerMsgStatus after running $spamtest->check(). I
> thought, I have to run check(), in order to get the PerMsgStatus object?
The code is what it is. Does the documentation imply that you can do anything
you want with PerMsgStatus object when you have it?
> Additionally: could you please test my sample code on a 3.4 SA environment?
> I've just checked and the got_hit() after check() seems to be working there.
It makes no difference how your "incorrect" code behaves between 3.4 or 4.0.
The basic logic of PerMsgStatus->check() has been the same atleast since 3.3,
check() for all purposes finishes the scan and you should only read the
results. It makes no sense to start changing this logic. Even if 3.4 registers
the got_hit(), internal state will be left inconsistent.
--
You are receiving this mail because:
You are the assignee for the bug.
--- Comment #4 from Henrik Krohns <apache@hege.li> ---
(In reply to Andreas Erhard from comment #3)
> Thanks for showing a possible workaround.
>
> I do understand your argumentation, but to me it sounds wrong, that you
> can't call got_hit() on PerMsgStatus after running $spamtest->check(). I
> thought, I have to run check(), in order to get the PerMsgStatus object?
The code is what it is. Does the documentation imply that you can do anything
you want with PerMsgStatus object when you have it?
> Additionally: could you please test my sample code on a 3.4 SA environment?
> I've just checked and the got_hit() after check() seems to be working there.
It makes no difference how your "incorrect" code behaves between 3.4 or 4.0.
The basic logic of PerMsgStatus->check() has been the same atleast since 3.3,
check() for all purposes finishes the scan and you should only read the
results. It makes no sense to start changing this logic. Even if 3.4 registers
the got_hit(), internal state will be left inconsistent.
--
You are receiving this mail because:
You are the assignee for the bug.