Bug overview description.
Was attempting to look at pictures that i HAD NOT favorite by using the filter bar. i typed in "-fav:razorrazer" yet it would still show the ones that i had added to my list. I have made sure i didnt hit the cap of favorite art. It just seemed to stop working at the moment.
What part(s) of the site page(s) are affected?
Searched gallery
What is the expected behavior?
Reduced list of items
What actual behavior is given instead?
All searched keywords are correctly filtered EXCEPT "-fav:"
Can you reproduce the bug every time?
At the moment yes
What steps did you take to replicate this bug?
Just used the "-Fav:" tag

So.. i miiight be working now? In a way.
Its VEEEERY slowly, removing pictures one by one every 5 minutes or so. The first one i added was finally filtered out, and then as i posted this a second one a few minutes later from the searched gallery. It could be things just working slow, but that's what i see so far.

I can confirm this with the "-upvote:" tag as well.

Seems to more or less be working as intended now. Dunno what was wrong. Things are still a few second slow, but not the long 15 minutes they were previously, at least for me.

There are some big website processing tasks happening right now, so a lot of small changes (like favorites, tag edits, etc) might take a few minutes to be fully processed. They will still work, but updating these things in search results will happen at a much slower speed than normal. It is basically making smaller changes wait in line, and completing them as soon as it has a free second. So that's why they don't happen instantly at the moment.

It will all go back to normal speeds when the site finishes processing the other big task. So for right now, it might be easier to just come back to what you were doing in an hour or so.

A huge round of tag changes just got approved. The search engine gives up the ghost whenever this happens - last time was when the Pokémon tags were reorganised into generation subcategories, causing every new Pokémon post to be effectively shadowbanned for about 24 hours. You should expect continued flakiness over the next few days as more requests get approved.

The good news is, after this you'll never have to figure out what the hell a phalangeriform is again.

kora_viridian said:
Is there any place where regular users can get a report of the current alias/BUR queue length, or ETA of empty queue, or something like that? If big updates are known to make the lights go dim for a while, it might be useful to have something to point people at, or that people could check on their own.

I don't know if there's a better way to check, but this can often give you some information if you filter the alias and the implications pages for 'processing'.

https://e621.net/tag_aliases?commit=Search&search%5Bstatus%5D=Processing
https://e621.net/tag_implications?commit=Search&search%5Bstatus%5D=Processing

It will show you what it is currently chewing through (if anything). If that looks very full with too many big things, and it's acting slow to update changes in search results... then that is why. The processing space is just busy right then. It's not super common for this to happen, but sometimes there's a big one that just has to go through. And also filtering by 'queued' on those pages can see if there's a ton of alias/implication tasks waiting for the next available space to get processed next. But right now, a lot of it looks like the list is getting pretty short. So it might be clearing up soon.

.. isn't filtering on status=queued more relevant to kora's question?

(FWIW when i checked there were 3 implications queued + 1 alias processing.)

savageorange said:
.. isn't filtering on status=queued more relevant to kora's question?

(FWIW when i checked there were 3 implications queued + 1 alias processing.)

Well there's two factors. The slowdown symptoms come when the 'processing' has multiple things in it at the same time AND they're each pretty big in size. So checking that first is the quickest way to know if something is going on there. You can also estimate how fast it will be done by refreshing that page to see how fast the numbers changed. So it is the most direct feedback on what it is doing and how fast it is doing it.

The 'queued' only tells you if there's a lot of other stuff waiting, and it may be empty if everything is already in 'processing'. Which makes it a lot less informative to check first. So that's why I suggested checking processing first, and then queued after that if you want to see the bigger picture. And if processing is empty for both, then there's probably nothing in queued so that order just saves you time. Also checking these on both the aliases and implications pages, because sometimes processing can "empty" or sit paused on one of them while it waits for the other to finish a few, before it pulls more from the queue. So checking only one of these four places can sometimes be misleading.