I wonder if FilterNotFoundException should be some level of normalized exception, because these were appearing for a variety of numbers...

Let's see:

wikiadmin2023@10.64.131.10(cawiki)> select max(af_id) from abuse_filter;
+------------+
| max(af_id) |
+------------+
|         25 |
+------------+
1 row in set (0.000 sec)

meaning it definitely does not exist. Where does the 222 ID come from? Following the trace, the integer is extracted in AbuseLogger.php#118. I don't see anything in GlobalNameUtils::splitGlobalName() that might go wrong, hence following $filter. But that in turn comes from FilterRunner, so I'm still not sure how it could've ended up there.

Also, considering that global filter 222 does exist, presumably this is a regression where something is not passing the appropriate flag for global filters.

In T390904#10705813, @Reedy wrote:

I wonder if FilterNotFoundException should be some level of normalized exception, because these were appearing for a variety of numbers...

Yeah, I think it should. It should be a simple change and I can review, otherwise I'll make a patch but first I want to find where the regression is.

Change #1133524 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@master] AbuseLogger: use the correct `global` flag for filter entries

https://gerrit.wikimedia.org/r/1133524

In T390904#10705870, @gerritbot wrote:

Change #1133524 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@master] AbuseLogger: use the correct `global` flag for filter entries

https://gerrit.wikimedia.org/r/1133524

Thanks. Taking a look at the patch.

Change #1133538 had a related patch set uploaded (by Dreamy Jazz; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@wmf/1.44.0-wmf.23] AbuseLogger: properly distinguish between global filters and central DB

https://gerrit.wikimedia.org/r/1133538

Change #1133524 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] AbuseLogger: properly distinguish between global filters and central DB

https://gerrit.wikimedia.org/r/1133524

Change #1133538 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@wmf/1.44.0-wmf.23] AbuseLogger: properly distinguish between global filters and central DB

https://gerrit.wikimedia.org/r/1133538

Mentioned in SAL (#wikimedia-operations) [2025-04-02T21:35:02Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1133538|AbuseLogger: properly distinguish between global filters and central DB (T390904)]]

Mentioned in SAL (#wikimedia-operations) [2025-04-02T21:41:34Z] <dreamyjazz@deploy1003> dreamyjazz: Backport for [[gerrit:1133538|AbuseLogger: properly distinguish between global filters and central DB (T390904)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-04-02T22:00:21Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1133538|AbuseLogger: properly distinguish between global filters and central DB (T390904)]] (duration: 25m 19s)

In T390904#10705813, @Reedy wrote:

I wonder if FilterNotFoundException should be some level of normalized exception, because these were appearing for a variety of numbers...

Want to do that in a different task? :)

To clarify on the risk of data corruption, me and @Daimona found that for local log entries (coped from etherpad):

• If the ID of the global filter does not exist as a local filter, we get an uncaught exception (T390904), so no log entry is written and that's good.
• If the ID of the global filter also exists as a local filter, the variable dump is unaffected unless:
  • The local filter was not protected and the global filter was protected. In this case, the variable dump will have no "user_unnamed_ip" variable included.
    • There is only one protected global filter. The only log entries in the last couple days are for a group2 wiki, so no entries affected.
  • The local filter was protected and the global filter was not protected. In this case, if the action also matched any protected filter the "user_unnamed_ip" variable will be present in the variable dump. This is the status quo (i.e. behaviour before the problem patch)
  • The "user_unnamed_ip" variable value is expired after 90 days and can be looked up separately (private details for an AbuseFilter log).
• In all cases, any problems would either be the status quo before the patch or can be worked around as needed. We hide the value of protected variables in public logs, so there is no risk of showing private data to those who cannot see it.

Global log entries were unaffected by any issues.

Change #1133561 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@master] Make FilterNotFoundException a NormalizedException

https://gerrit.wikimedia.org/r/1133561

In T390904#10706214, @Dreamy_Jazz wrote:

To clarify on the risk of data corruption, me and @Daimona found that for local log entries (coped from etherpad):

Yup, and for the papertrail, I later verified that no filter is affected in production (group0 and group1 only).

Change #1133561 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Make FilterNotFoundException a NormalizedException

https://gerrit.wikimedia.org/r/1133561