Page MenuHomePhabricator

Add "Manual Activities", to tell administrators to rebuild the search index
ClosedPublic

Authored by epriestley on Nov 30 2016, 6:47 PM.

Details

Summary

Ref T11922. After updating to HEAD of master, you need to manually rebuild the index. We don't do this during bin/storage upgrade because it can take a very long time (secure.phabricator.com took roughly an hour) and can happen while Phabricator is running.

However, if we don't warn users about this they'll just get a broken index unless they go read the changelog (or file an issue, then we tell them to go read the changelog).

This adds a very simple table for notes to administrators so we can write a "you need to go rebuild the index" note, then adds one.

Administrators clear the note by completing the activity and running bin/config done reindex. This isn't automatic because there are various strategies you can use to approach the issue, which I'll discuss in greater detail in the linked documentation.

Also, fix an issue where bin/storage upgrade --apply <patch> could try to re-mark an already-applied patch as applied.

Test Plan
  • Ran storage ugrades.
  • Got instructions to rebuild search index.
  • Cleared instructions with bin/config done reindex.

Diff Detail

Repository
rP Phabricator
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley updated this revision to Diff 40826.Nov 30 2016, 6:47 PM
epriestley retitled this revision from to Add "Manual Activities", to tell administrators to rebuild the search index.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad accepted this revision.Nov 30 2016, 7:09 PM
chad edited edge metadata.
This revision is now accepted and ready to land.Nov 30 2016, 7:09 PM
avivey added a subscriber: avivey.Nov 30 2016, 7:14 PM

Couldn't we add a worker to invoke the re-index, and have a "migration" schedule that worker?

We could, but I think that approach is likely to have a higher support cost overall than this one:

  • If there are errors, they'll be pretty much invisible.
  • If there are errors and that worker restarts, we'll potentially flood the task queue with infinite reindex tasks.
  • If there are errors and that worker does not restart, we'll just end up with a silent failure and broken search -- (or some version of this change, anyway, that tells administrators that the worker failed).
  • Administrators won't get any sort of notice about why search isn't working for a few hours (or longer) after an upgrade.
  • Administrators won't have an opportunity to schedule the queue getting all this stuff dumped into it at an off-peak time.

I don't really like this mechanism and I'm not sure we'll ever use it for anything except search index rebuilds, but I think we'll get into more trouble overall by trying to make this happen automatically.

This revision was automatically updated to reflect the committed changes.