Incidents/2022-09-09 Elastic Autocomplete Missing

==Summary==
Wikimedia users noticed "weird and unhelpful search results," specifically with regards to autocomplete, as documented here. This was an unexpected result of changes related to Search Platform's Elasticsearch 7 upgrade.
==Timeline== 
All times in UTC.
*1 September 2022: The Elasticsearch 7 upgrade plan includes a planned switch from Eqiad to Codfw, where Codfw is upgraded first, then we switch traffic, and once Eqiad is upgraded we switch back. This was set in wmf-config by automatically switching based on the next MW branch.
*7 September 2022: ElasticSearch maintenance script runs from MediaWiki 1.39-wmf.27 branch (old branch, only compatible with ES6) and tries to build indices on Codfw, which run ES7 already. Unbeknownst to us, this rebuild silently failed in Codfw.
*8 September 2022, 21:18:44: The train rolls out 1.39-wmf.28 to all wikis (schedule, SAL) and traffic switches to Codfw as planned, effectively exposing the failed indices to live traffic.
9 September 2022:
*00:18: Autocomplete caches expire. START OF ISSUE. Matching time Wikipedia editors report first observing it ("as of around an hour" at 1AM).
*01:00: Wikipedia editors report "weird and unhelpful search results", specifically with regards to autocomplete.
*02:13:24: Legoktm reports the issue to the team in IRC #wikimedia-search.
*05:10:37: ebernhardson switches $wgCirrusSearchUseCompletionSuggester to use build (disabling the completion suggester, falling back to prefix search) to work around the issue. Autocomplete caches for 3 hours, so in worst-case scenario, users impacted until 08:10:37.
*08:10: END OF ISSUE.
*14:00: PoolCounter rejections increase to around 5% due to use of prefix search as opposed to CirrusSearch-Completion (this is a QoS limitation as opposed to a resource limitation).
*14:30: PoolCounter rejections drop as CompletionSuggestor is re-activated via this patch.
==Detection==
Detection: users reported the error
Alerts: None
==Conclusions==
===What went well?===
* ebernhardson quickly realized the root cause and worked around it.
===What went poorly?===
* Monitoring did not detect the issue
* We did not realize this could happen and thus did not include it in our ES7 rollout plan
* We did not communicate adequately around the upgrade.
===Where did we get lucky?===
*ebernhardson was still online after work hours, and was able to address the issue.
==Links to relevant documentation==
* None
==Actionables==
*Create documentation on UpdateSuggesterIndex.php, probably should go on the Search page
*Better monitoring, specifics to be added later
*Sanity-checking for index size/age 
*Pool counter limits should be verified against what's running in production (CompletionSuggest limits are much higher than PrefixSearch, and when we gracefully degrade to PrefixSearch, we need more slots for PrefixSearch). Probably add this as a test this in mediawiki-config.
*Better communication, so others are aware when we roll out a major version change.
==Scorecard==
Incident Engagement ScoreCard
 	Question 	Answer
(yes/no)	Notes
People 	Were the people responding to this incident sufficiently different than the previous five incidents? 	yes	
People 	Were the people who responded prepared enough to respond effectively 	yes	
People 	Were fewer than five people paged? 	yes	
People 	Were pages routed to the correct sub-team(s)? 	no 	
People 	Were pages routed to online (business hours) engineers?  Answer “no” if engineers were paged after business hours.	yes	
Process 	Was the incident status section actively updated during the incident? 	no 	
Process 	Was the public status page updated? 	no 	
Process 	Is there a phabricator task for the incident? 	yes	
Process 	Are the documented action items assigned? 	no 	
Process 	Is this incident sufficiently different from earlier incidents so as not to be a repeat occurrence? 	yes	
Tooling 	To the best of your knowledge was the open task queue free of any tasks that would have prevented this incident? Answer “no” if there are
open tasks that would prevent this incident or make mitigation easier if implemented.	yes	
Tooling 	Were the people responding able to communicate effectively during the incident with the existing tooling? 	yes	
Tooling 	Did existing monitoring notify the initial responders? 	no 	
Tooling 	Were the engineering tools that were to be used during the incident, available and in service? 	yes	
Tooling 	Were the steps taken to mitigate guided by an existing runbook? 	no 	
Total score (count of all “yes” answers above)	Total score (count of all “yes” answers above) 	9