Report site bugs here

@Derpy Whooves  
Tried a search for “Trixie” and set the filter to Maximum Spoilers, Everything, and Default. In all cases one of the 24 most recent Trixie images is still missing, even on Everything.

Can you describe the image or give me the same search that you are using, or which tag you are watching that should return the image?
 
For example, there are 27 images with Trixie in them that you favorited that have been deleted - it might be one of those, I’m thinking. I just don’t know which one.
 
UPDATE: I sent you a screenshot of all the images with Trixie in them that you have favorite that were deleted because of mergers or artist requests - please let me know if the missing image is in that set, and I’ll find out what happened to it.

In my case the tag I watch is Cheerilee. It happens on several of the tags on >>254 if you want to check those out, and what I determined to be the missing image ID seems to have been merged with that older upload…

@Wiimeiser  
>>1951906 (merged) was merged into that image … but if you’re watching tags on that image, you should still see >>254, so it wouldn’t be “missing”.

Okay, so it’s between these two images: >>1951904 and >>1951907. There are no images between those two, despite a big id gap (skipping from …904 to …907). At least there are no visible images.
 
When I managed to make >>1951907 show up at the end of the page, the bug showed up as well. I was basically doing searches and adding “-oc:some oc name”, intil the bug showed up on the page.

@Background Pony #0E4F  
>>1951905 exists as it was uploaded, and >>1951906 (merged) was merged into >>254. But >>254 should still show up if you’re watching the tags that are on >>1951906 (merged)

Oh, wait, my bad. There are visible images between. I filtered RD as well at some point during my tests.
 
Welp, back to testing.

@Derpy Whooves  
The problem, then, appears to be >>1951906 (merged) not being properly cleared from the index, so searches that would return the tags on it are still returning it, but the image itself no longer exists…

@Wiimeiser  
Can confirm, it’s >>1951906 (merged). When a page ends at >>1951907 - no bugs. When I remove one more image, so a page would have to end at >>1951906 (merged) - the bug shows up.

@Wiimeiser  
@Background Pony #0E4F  
Can you please tell me what search string you are using?

@Derpy Whooves  
I mean, I can (the last one I used was “safe, -ts, -oc:velvet passion”, filter “everything”, bug showed up on page 22), but I’m not sure what are you expecting to get out of it. New images are always uploaded, so image positions are always shifting, and by now my search string is pretty much useless. (also I have 24 images per page, which I don’t know if it’s standard or not).

@Derpy Whooves  
If you want some interesting search strings, try:  
“trixie, safe” - bug shows up right away.  
“artist:tomatocoup” - bug shows up right away.  
“artist:tomatocoup, ~~trixie” ~~ bug doesn’t show up.  
“artist:tomatocoup, ~~playing cards” ~~ bug doesn’t show up.

@Background Pony #0E4F  
The image was merged as it was a duplicate of image >>254.

Found it. This search exposes the issue:
 
artist:tomatocoup,created_at:2019-02-03. Basically the image is being returned by searches, but it is not shown, so what you see is one fewer images than expected.
 
If you aren’t on staff you just see “one fewer than expected” image.
 
I’ve never seen this before, and rather than try to fix it by repairing or redeleting the image, I’ve reported this to the site developers so they have the image to look at for clues.

@Derpy Whooves  
It must have not had its index updated, I’ve fixed that.

@Princess Luna  
Fixed!

@Derpy Whooves  
@Princess Luna  
Can confirm: it’s fixed.
 
Thanks guys :3

@Princess Luna  
@Derpy Whooves  
@Background Pony #0E4F  
Fixed on my end, too. Thanks

@Wiimeiser  
Sorry for taking so long to figure out what the problem was - we literally see something different than what you see. But once we had it down to apples versus apples (thank you for helping in the PM) it was obvious that something was donked up.

LOL that was all partially my fault; I re-uploaded the Trixie card trick image last night because the artist:su-26 tag wasn’t aliased to artist:tomatocoup at the time– it is now, apparently– and it was so old that I didn’t even realize su-26 was one of tomatocoup’s old blog names, so I thought that it had simply been overlooked when it was originally posted on Tumblr 7½ years ago because it only had like 5 notes, and surely an image that gorgeous would have had more likes/reblogs if it had been posted here on Derpi.
 
My re-upload seemed to have been deleted by the auto-dedupe robot while I had the the tag edit field open on it, did that maybe have something to do with why it was causing problems elsewhere?

@TexasUberAlles  

 
That may have done something, actually. Reminds me of a bug in Touhou 11 for some reason…

@icey wicey 1517  

 
Anyone else having this issue or is it just me?

Found a bug while developing a Rust API for this site. uploader_id in images object in gallery json is a string while on other endpoints it’s an integer.
 
Edit: It seems tag_ids are also strings
 
For example:  
gallery  
image

I just got randomly logged out while still browsing the site. But I’m not sure if it’s a bug or if it’s just the “automatic log out after a certain amount of time” thing.

That has happened to me once before, so I doubt it’s a bug. Can’t remember what I did, but iirc I didn’t set “Remember me” checkbox.