Page MenuHomePhabricator

When "cluster.search" changes, don't trust the old index versions
ClosedPublic

Authored by epriestley on Apr 2 2017, 4:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 11, 9:10 AM
Unknown Object (File)
Sat, Apr 6, 8:46 PM
Unknown Object (File)
Fri, Apr 5, 5:59 AM
Unknown Object (File)
Mar 15 2024, 6:39 PM
Unknown Object (File)
Feb 20 2024, 10:51 PM
Unknown Object (File)
Feb 20 2024, 1:48 PM
Unknown Object (File)
Feb 20 2024, 6:53 AM
Unknown Object (File)
Jan 25 2024, 4:00 AM
Subscribers
None

Details

Summary

Ref T12450. We track a "document version" for updating search indexes, so that if a document is rapidly updated many times in a row we can skip most of the work.

However, this version doesn't consider "cluster.search" configuration, so if you add a new service (like a new ElasticSearch host) we still think that every document is up-to-date. When you run bin/search index to populate the index (without --force), we just do nothing.

This isn't necessarily very obvious. D17597 makes it more clear, by printing "everything was skipped and nothing happened" at the end.

Here, fix the issue by considering the content of "cluster.search" when computing fulltext document versions: if you change cluster.search, we throw away the version index and reindex everything.

This is slightly more work than we need to do, but changes to "cluster.search" are rare and this is much easier than trying to individually track which versions of which documents are in which services, which probably isn't very useful anyway.

Test Plan
  • Ran bin/search index --type project, saw everything get skipped.
  • Changed cluster.search.
  • Ran search index again, saw everything get updated.
  • Ran a third time without changing cluster.search, everything was properly skipped.

Diff Detail

Repository
rP Phabricator
Branch
search4
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 16254
Build 21599: Run Core Tests
Build 21598: arc lint + arc unit