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
F14081117: D17598.diff
Fri, Nov 22, 6:29 PM
Unknown Object (File)
Mon, Nov 18, 9:40 AM
Unknown Object (File)
Thu, Nov 14, 10:45 AM
Unknown Object (File)
Sun, Nov 10, 7:06 AM
Unknown Object (File)
Wed, Nov 6, 8:06 AM
Unknown Object (File)
Oct 22 2024, 6:55 AM
Unknown Object (File)
Oct 20 2024, 9:21 PM
Unknown Object (File)
Oct 18 2024, 1:09 PM
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
Lint
Lint Not Applicable
Unit
Tests Not Applicable