And we're back!

If it's any help for the sake of reproduciblity, I only just now ran into this issue (I'd heard about it in the past, but never experienced it myself) with the only recent change being that I logged myself out of my Wikipedia account a few days ago (this is the first time I've opened Huggle since then). I've dumped the relevant logs in P30996.

It might be worth noting that Thumbor's 4xx's (namely 404s) do currently show 5xx "something-internal-went-wrong"-style error pages since T169683, which is mildly misleading to end users who (somehow, though I'm not sure how myself) end up on a 404-ing thumbnail page. (See Ticket#2022041410003305 on VRT).

It looks like eqiad replication lag (I'll see if I can confirm with someone outside of that region) is currently all the way up to 10 weeks, so that's probably it. Seems possibly related to T218097,

peirik mentioned on IRC that this does look good, as do I agree. Eventually we'll have a longer-term solution from T306660 but the new 1000 px threshold does seem sufficient to close this issue for now. (Leaving open in case QA needs to do something first?)

In T298854#7607990, @Joe wrote:

Sadly that code search is not a complete guarantee. For things we build with the pipeline, we might not have a package.json for all dependencies, so we will have to do a manual check of the docker images.

It appears to be down again. @Petrb or @bd808, are one of you able to re-poke it awake again?

From @bd808: "[03:07:21] bd808: I think what happened is that the redis queue filled up because the consuming script was down. I'm going to reboot the instance and then check back to see what has to be manually started."

We're on PHP 7.2 now and the part mentioned earlier has been struck in the standard, so this may be worth a second look.

In T181344#5196227, @simon04 wrote:

See T181344#4652876 for my way of solving it.

In T275234#7361977, @Perryprog wrote:

This issue has been reported on Znuny on Ticket#2021091710000804, so it's safe to assume the problem is still present.

This issue has been reported on Znuny on Ticket#2021091710000804, so it's safe to assume the problem is still present.

See also T228121.

Correction—it actually removes the first input (i.e., the topmost one), which is strangely mildly amusing.

Hm—on second thought, you're probably right @Barkeep49. I take back what I said earlier.

For what it's worth, my experience with OTRS so far hasn't been too bad. It does what it really needs to do, just with... a lot of downsides. (Slow, bad UX, limited functionality, etc.)

I'm running macOS Big Sur, here's some more screenshots with rules.
Safari 14.0.2:

I haven't come across the original issue either (I haven't specifically tried to reproduce it, but I do use custom shortcuts). I do know that certain shortcuts like Shift+D don't work at all because they're hardcoded (see T213008), but for the most part they've worked fine for me. (Big Sur, Huggle version: 3.4.10, build: 3880 3.4.10)

I personally mark edits suspicious when I believe them to be non-constructive, but I'm unable to explain why, in policy, it should be reverted.[1] In other words, it's a "this is probably a bad edit, but I want a second user to look at it" button for me—the ephemeral nature of it is partly why I find it especially helpful.

A check somewhere (not sure where)

If it helps at all, I believe that would be here, with the blocked param being defined from User::isBlocked here.
Edit: naturally, I missed @Dreamy_Jazz's much more informative break down of the call tree here.

Sorry, let me clarify. Displaying the message "No difference" like that seems to be very inconsistent with the way diffs are usually displayed. It also shows a lot of extraneous information that isn't relevant to just saying "No difference".