Today my trusty search for newest zero-answer C# questions:

which is basically "answers:0 [c#]" and switch to the "newest" tab, returns questions starting nine hours ago and it includes questions with answers:

enter image description here

share|improve this question
[status-norepro] for me. Are you ignoring the C# tag? –  Robert Harvey May 12 '11 at 23:08
No, not ignored, but it is a favorite. That causes the flesh tone background in the hits above. If I do the same search in a different browser without my SO login it show the same first three hits now from fifteen hours ago and has the banner bar "Welcome to Q&A ..." so it is seems unrelated to my account and is still reproducible here, albeit staler. –  Rick Sladkey May 13 '11 at 1:15
Partly reproducible for me, sorting is correctly and the newest question is 36 minutes old...*but* the first and third question does have an answer. –  Time Traveling Bobby May 13 '11 at 7:13
Can you still get this behavior? The 9 hours behind sounds very odd - we haven't had indexing issues in some time. The answers on the top few can happen, since we index every 15 minutes (30 at most - if there's a build in-between), and if an answer is added in the last 15 minutes, you may see that result. –  Nick Craver Jun 13 '11 at 10:25
@Nick: This problem was confined to that day; I haven't seen it since. But judging from the upvotes, others some could repro it on that day. The tag [status-nonrepro] is fine. It was a real phenomenon for me but it was a transient problem. –  Rick Sladkey Jun 13 '11 at 15:36
@Rick - I misread the dates, May 12th (I read yesterday) we did have a build issue with lucene on certain servers (app pools not actually dying), this was an issue then - which should have been resolved that night, making this [status-completed]. –  Nick Craver Jun 13 '11 at 17:48
add comment

1 Answer

up vote 2 down vote accepted

There was a build-related issue on this day where some app domains just didn't want to die - even when the web sites were stopped in IIS, causing some indexing overlap which caused quite a few issues on certain web servers.

In our setup users are sticky mapped to a web server, so if you mapped to one having issues, you would have seen greatly lagged indexes, the 9 hours you see in the screenshot above is an example.

We resolved this and added a few more safeguards around so hopefully the prolonged overlapping app domains won't cause issues again (though they shouldn't have happened in the first place...)

share|improve this answer
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .