[ SmokeDetector | MS ] Link at end of answer, pattern-matching website in answer, username similar to website in answer: Mirrored numbers by RFplus on puzzling.SE
tpu- by CalvT븃
10 second backoff on request to questions/340261?site=physics
@Magisch It’s not actually a leak though – the people who reported it seem trustworthy, and there’s no evidence AFAIK that someone else has a copy of the data.
@CalvT븃 I think that's the 3rd time since we re-implemented those. @Undo, it doesn't look like backoffs are a big deal. We've gotten three in the past 4-5 days.
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Title - Position 1-12: igesame.com Body - Position 1-12: igesame.com Username - Position 1-12: igesame.com
The 'max_rep' in findspam determines how we evaluate the post. Since the vast majority of spam is from low rep users, we have the thresholds set very low.
All this means is that Smokey trusts the more established users. If they are caught spamming, we can blacklist them and they will be dealt with by a local mod.
@Sconibulus We'd appreciate that warning. I'd also be interested in that particular puzzle :)
@Cerbrus That ^ Arabic(?) username seems to break the rep count display. If you put the username in a span with unicode-bidi: isolate in the CSS, the problem seems to be fixed.
I had a hypothesis that the poor performance we're seeing there was due to Art's API queue size changes causing backoffs, but that didn't end up being it
Still, the queue size changes are suspiciously well-timed.
Because I think how FIRE works is it only checks for deletion state when a user clicks the FIRE button, which could be multiple tens of minutes after the real deletion. If it sends a deletion log then, that skews stats heavily towards too long.