Yes this is caused by small timeout for revscoring queries and the fact that the webserver seems to have some performance issues I guess (but not sure). Revsoring queries are blocking edits from getting into the queue so for that reason timeout is set to about 5 seconds only. You can increase it in your configuration file, but in case webserver was down you would have severe delay before edits get in queue.

@Halfak can you check on server if there are some error logs related to this?

You can also resolve this issue by entirely disabling the revision scoring extension in preferences, just right click on it, disable and restart huggle. That will disable all ORES scores in huggle though, which are giving you hints on what is vandalism and what not.

Some edits take longer than 5 seconds to score , but they are relatively rare. If you get a timeout from ORES, I'd recommend trying to re-requesting the score. ORES internal timeout is 30 seconds.

To be precise the default timeout is 7 seconds, so it's longer

I am just wondering, why does ORES do this scoring everytime? So that when 10 users request score of same edit, it perform 10 CPU expensive computations just to do 1 thing 10 times.

Why you don't store the results to some cache?

No it doesn't duplicate computation and yes we use a cache.

You should expect to get most scores very quickly. You might get better performance if you send parallel requests (which is OK for < 50ish parallel requests).

What's your current data gathering pattern? One at a time & sequential? Batch a large N?

By T108305#1579938, it seems to request a single score per request.

https://en.wikipedia.org/wiki/Wikipedia:Huggle/Feedback#Huggle_scoring_fails.3F

In T110798#1614291, @Halfak wrote:

You should expect to get most scores very quickly. You might get better performance if you send parallel requests (which is OK for < 50ish parallel requests).

What's your current data gathering pattern? One at a time & sequential? Batch a large N?

It's processing a single edit at a time, if it wasn't doing that the performance of huggle would be significantly lower. It's also used on projects with low EPM, not only on english wikipedia, so waiting for more edits wouldn't make much sense there. People don't like waiting for batches of edits, they like constant flow of edits.

Of course. I wouldn't suggest sending a batch unless you have a batch to score. If you are scoring edits as they come in, I think that makes fine sense. I'd recommend requesting the scores in parallel though. E.g. if two edits come in faster that the first score can be returned, don't block. Async, or a proper thread might be in order.