I'm trying to use "infavorites:mine" search query on ru.stackoverflow.com to display list of questions marked as favourite. It displays no results, despite i do have some questions marked as favourites.
-
Possible duplicate of Seems infavorites:mine doesn't work globally.– Optimus PrimeSep 15, 2017 at 10:14
-
1Thanks for the heads up, we indeed switched the entire Elastic pipeline over yesterday and undoubtedly broke this. We'll get it fixed up ASAP.– Nick CraverSep 15, 2017 at 10:34
-
@NickCraver so, is that the cause for the blank text in related field too?– Optimus PrimeSep 15, 2017 at 10:43
-
1@redhand - probably. Elastic is the source of the data for related questions.– OdedSep 15, 2017 at 10:51
-
I see the favorites issue, it's a bit interesting so I'll detail below - testing fixes locally. We're still looking at related pulling in answers.– Nick CraverSep 15, 2017 at 11:58
-
@redhand Related is also fixed, separate issue but same upgrade/cutover of course. Dean's posting an answer over on those questions now - thanks for the reports everywhere! Much appreciated :)– Nick CraverSep 15, 2017 at 13:53
Add a comment
|
1 Answer
This is now fixed, some info on what happened in case people are curious:
Okay we had a few issues here as a result of the elastic migration we've been working on and just migrated to. For priority reasons (read: how much dev time it costs) we have punted on upgrading Elasticsearch for some time. The way we used it in 1.x was no longer compatible with 2.x. We learned a lot about our use cases with developer stories, company search, jobs, etc. that came after posts.
We changed the structure of our index and indexing in a way that was flexible to meet all these things using the TPL dataflow libs and now indexing is faster, more reliable, setup for A/B testing, resumable (Stack Overflow has 40 million posts, so this matters), and Elasticsearch 2.x and 5.x compatible. We'll be upgrading to latest 2.x Monday and then hopefully 5.x (overall latest) the following week. There's a hop here because of multi-hour index rebuilds.
The architecture team has been working on this lately, motivated by the search needs of Channels. While it's for Channels, all of Q&A will benefit. So why do Channels matter?
The layout of Channels is a site per SQL schema. While this works fine in SQL, an index per Channel (how we use Elastic today for all sites) doesn't scale to hundreds of thousands. We need to fold all these relatively tiny indexes together or in sets and have search still work. This breaks some things as you saw here.
Instead of the ID of a document being say the PostId (e.g. the question ID in the URL of this page you're on), it has to be something different, because Channel 1,2,3,4,5, etc. all have Post.Id=1. So we now have "_id" = "{SiteId}-{PostId}" in the shared Channels index. For the curious: ultimately, we'll likely be using filtered index aliases here, as SiteId (or ChannelId) is also a field in the document now.
How this matters: for infavorites:mine, what we do is query SQL, find your favorites, then use an ids query and filter to those. But after this change, those no longer matched, because "{PostId}" isn't "{SiteId}-{PostId}". Woops, we missed this. We need to append the "{SiteId}-" prefix on that IDs query for it to work.
We want to do a lot of things to improve search but all were behind a massive technical blocker we're unblocking with these moves. Stay tuned for ideas we want to pitch here to improve search across all Q&A sites. We agree it's long overdue.
answered Sep 15, 2017 at 13:51
