Page MenuHomePhabricator

AbuseFilter logs warning "parser error for filter {num}: {parser error}"
Closed, DuplicatePublic

Description

Error

Request ID: XIc4TQpAAEoAAJA3OMUAAABF

message
AbuseFilter parser error for filter {num}: {parser error}
examples
AbuseFilter parser error for filter 142: Unexpected "T_OP" at character 157.

AbuseFilter parser error for filter 175: Expected a ) at character 41, not found (found T_OP * instead).

AbuseFilter parser error for filter 17: Invalid IP range{*** provided at character 297.

Impact

Unknown.

If these are filters just broken due to bad user input, they presumably don't need logging. Or perhaps at "debug" level with wmf-config to ensure it is only logged in XWD mode, and not by default. For general understanding of disabled filters, there are (or should be) other more general metrics, e.g. via Statsd, not in Logstash.

If these are due to a bug in the software, then this is appropriate as warning currently, and might be a high priority, given it triggers several million times a day.

Notes

This warnings has been seen at its current frequency of 2 million per day, for at least 30 days.

Event Timeline

Krinkle created this task.Mar 12 2019, 4:48 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 12 2019, 4:48 AM

@Krinkle Those filters being broken is indeed a software bug: every filter is syntax-checked upon saving, so ideally no filter should ever fail at runtime. Which is why I raised the logging level in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/482777/. And yes, it's also high priority, although this has no impact for the end user and, I think, it doesn't affect AbuseFilter result.