Thanks for the examples. As you may have noticed, and as Erik pointed out above, the behavior you are noticing is section title highlighting working as intended, even if it is not the best experience. We do not and cannot currently index sections as searchable documents. When section titles are highlighted in search results, this is due to part of the search query matching the specific text in that section title itself, not because of any kind of relevancy of the section's content.

For more clarity, at the point of withdrawal from the process, this ticket was at the stage where Search was unblocked from moving forward. We have a RACI card filled out based on feedback, which we still intend to use to communicate our plans as we move forward. There were multiple upcoming phases of shopping ideas around for feedback, but I was told that this feedback would not be binding or a blocker to continue our work, but as additional points of perspective to consider.
Given that this is a minor component that was holding up our larger Elasticsearch version upgrade, I expressed concern that these additional stages were creating busy work that put our timelines at risk. Based on the size and impact of removing API Feature Usage's dependency on Elasticsearch, I was given the go ahead to move forward with this work without moving through the final steps of the Tech Decision process, which were understood to be more of a formality at this stage.

@cchen , looks like maybe the gobar_search numbers for ptwiki and ruwiki are off

Sorry for all the confusion. This process is new to me, and I don't yet fully understand how it works and what communication practices/norms are.

The ticket was declined because @SWakiyama cleared my team to move forward with this work without pushing it through the rest of the Tech Decision process.
I was under the understanding that this unblocked this work for the search team.

@Reedy , is there a reason this ticket was declined?

It seems like this is a nice to have since the user could still type more of the language name out in order to either complete it by only typing, or enough that the number or suggestions is small enough to select from (i.e. by the time I type Englis, the language suggestion is probably pretty high)?
Do you happen to have data on how often people use the suggestions? or might use it if it works well?

Updated ticket to reflect that this is about the order of autocomplete suggestions, and not (full text) search results (these are two different processes on the backend -- yes, this is a little confusing and should probably be addressed elsewhere)

For extra context, the reason for this behavior is that trying to merge and filter such a high volume of results on each shard of our search cluster could crush our servers and bring down our search services.

@cchen

Based on last week's check in meeting, I think Erik's comment is a sufficient answer and we can close this ticket

Thanks @cchen ! This is great.

I don't think for performance reasons we can/want to run any kind of full text search in the go bar, so this will likely be a declined task, or low priority one, unless there are other solutions I'm not thinking of.

@TJones can correct me if/where I'm wrong.

cc: @cchen , in case you have some additional insight into what search instrumentation/metrics are currently available