Page MenuHomeMiraheze

Internal Error while Batch Testing with Abuse Filter
Closed, ResolvedPublic

Description

Hi,
On this wiki which I am an administrator on, I was creating an Abuse Filter which I went to go check against some previous edits (to check if it worked or not) and when I clicked the "test" button, this error message came up:

Internal error
[62ad6a390360a73519bf9b0e] 2021-05-12 04:47:00: Fatal exception of type "TypeError"

Can anyone help with this issue? Thanks!

Event Timeline

Turtle84375 triaged this task as Normal priority.May 12 2021, 04:51
Turtle84375 created this task.
Reception123 added a project: Upstream.

I've also noticed this. This is an upstream issue so unfortunately there's nothing Miraheze can do about this except wait for upstream to fix it. See https://phabricator.wikimedia.org/T281193

I've also noticed this. This is an upstream issue so unfortunately there's nothing Miraheze can do about this except wait for upstream to fix it.

Ah. Fun. Oh well, it's not too vital a feature on Allpedia. Thanks for letting us know.

I can see a straightforward solution actually. Miraheze can just test this patch on test3 and if it goes well, apply it to production wikis.

In T7290#144802, @R4356th wrote:

I can see a straightforward solution actually. Miraheze can just test this patch on test3 and if it goes well, apply it to production wikis.

We've never in our history applied a patch on top of core to an extension.

We've done it for core both publicly and for security issues before but never an extension to my knowledge.

If hacking core is okay then I cannot see why hacking a global extension is an issue.

Because core is just files and not updated that regularly. Extensions are sub modules and updated much more often.

I can see at the next update run it just being over ridden and no one seeing.

Unknown Object (User) added a comment.May 12 2021, 08:46
In T7290#144802, @R4356th wrote:

I can see a straightforward solution actually. Miraheze can just test this patch on test3 and if it goes well, apply it to production wikis.

We've never in our history applied a patch on top of core to an extension.

We've done it for core both publicly and for security issues before but never an extension to my knowledge.

I think we have before, there used to be a miraheze specific patch to Cookie Notice (though isn't anymore) or am I misunderstanding here?

I don't think starting to hack extensions is the way to go, as it would be a slippery slope and we can't possibly manage all that. Also for the reasons given by RhinosF1 regarding updates and so on, there would be merge conflicts / overrides and it would just not be practical to do so.

I understand the concerns but still think that "hacking" is the way to go if Miraheze wants to make sure all global extensions maintained by the WMF work. We all know that the WMF are lazy folks (to put it bluntly) and do not really care about third parties. It is unlikely that the issue will be fixed anytime soon. If the issue cannot be fixed by Miraheze, then AbuseFilter should be turned into a default extension so that annoyed users can at least turn it off.

AbuseFilter is not getting turned off because of this.

Having a proper way to apply custom patches, including security ones, would be nice but that's quite far off yet.

It's understandable that it's annoying to have upstream be slow and not immediately fix patches but it's also not possible to shift that responsibility towards Miraheze and have us having to track locally applied changes to extensions. One may say that this one is more important than others, but if we would do one then everyone will ask us to apply upstream patches and that is just too much for us to manage I think. Either way, as RhinosF1 says I'm not aware of there being a proper way to do this. Turning off AbuseFilter doesn't make sense either because this is just one individual functionality that doesn't work.

Unknown Object (User) closed this task as Invalid.May 12 2021, 21:41
Unknown Object (User) assigned this task to Reception123.

Closing per original status again.

@Turtle84375 @R4356th Upstream has fixed this and I've updated AF.

Turtle84375 changed the task status from Invalid to Resolved.May 13 2021, 23:51
Turtle84375 awarded a token.