In these logs, new_wikitext and added_lines have JSON instead of the entity serialization in old_wikitext:
I cannot say under what conditions this happens though KasparBot triggered a filter many times as a result of this bug.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Don't filter undos coming in via the "APIEditBeforeSave" hook | mediawiki/extensions/AbuseFilter | master | +6 -0 |
Two of the linked changes are rollbacks... aren't rollbacks excluded from AbuseFilter at all? This could also indicate a bug.
I could reproduce this by undoing a content object using the api with action=edit&undo=…&undoafter=…. Will look into this further.
These weren't actual rollbacks, but emulated ones by @Ricordisamoa's https://www.wikidata.org/wiki/User:Ricordisamoa/Rollback.js.
The problem here got visible with @aude's a225cbdca89563e878c19580fb04c9e1d805d6c7 which made it possible to use ApiEditPage for undoing edits on entity content.
ApiEditPage always runs APIEditBeforeSave, even when undoing an edit. That is inconsistent with for example EditFilterMergedContent.
I see two ways to fix this:
Whatever we choose to do, we should document the (new) behavior of the hook properly (right now its not obvious whether it's supposed to run on undo or not).
@Anomie Given you moved this to not a core issue, I suspect you say that the core behavior shouldn't be altered?
Yeah, it makes more sense to me that the "ApiEditBeforeSave" hook would be called for all API action=edit calls, including undo.
Whatever conversion is applied to new_wikitext and added_lines, can't it be applied regardless of the action?
Change 278071 had a related patch set uploaded (by Hoo man):
Don't filter undos coming in via the "APIEditBeforeSave" hook
Change 278071 merged by jenkins-bot:
Don't filter undos coming in via the "APIEditBeforeSave" hook