For a extreme example, consider this filter:
How can it consumes 23296 conditions if the condition limit is set to 1000?
Why does that value changes every second?
(reloading the page a few times I got: 51172, then 3986, then 7859, 14690, and so on...)
This is very confusing for users trying to debug and optimize the existing filters...
T47045: Condition limit outrageously high after filter is disabled
T43691: Abuse filter inconsistent matching between testing and real checking
T57459: Include "condition limit consumed" column in AbuseFilter list
Original comment by Dragons flight on gerrit/201104
The AbuseFilter internal stats collection has been plagued by several bugs
for its entire history. The most prominent bug is caused by a race
condition where competing Apache instances can corrupt the data in
memcache. This is due to distributing stat data across multiple memcache
entries. Other stat corruption is associated with editing filters or
filter runs that abort due to reaching the condition limit.
The modifications here overhaul the stats system to solve these problems.
In particular, all per filter profile data is now hosted in an array
that is stored in memcache as a block so that the different stats
remain consistent. The restructuring also lays the groundwork for future
enhancements to the internal AbuseFilter profiling.