This is a known limitation for now. There is no plan to address this soon, but I also think that would be out of the scope of this task.

@GMikesell-WMF it is my understanding that the lead section is always supposed to be there, and this is the reason why even the parse endpoint doesn't return it in the tocdata response (e.g. https://en.wikipedia.org/w/api.php?action=parse&format=json&formatversion=2&prop=tocdata&page=Moon). So, I believe that the lead section can be empty, but not "missing", and it's never expected to be in the missing sections list.

I'm closing this task as irrelevant, as I could not find any occurrence of the issue for the last past year: https://logstash.wikimedia.org/goto/cbfe7bcab8860525d0dfdcd5406c96cb.

The target section title for missing sections is fetched from CXServer section mappings. E.g.
https://cxserver.wikimedia.org/v2/suggest/sections/2010%20Major%20League%20Baseball%20season/en/es?include_section_sizes=true.

Thank you @Volans, I can now run queries on super.wikimedia.org properly! Thanks to everyone involved! This task can be now resolved.

This task should not be closed as resolved, as easy suggestions on mobile are not really based on the lead section size, but still take into account the article size. In the example below (el production wiki with a "newcomer" user,), we can see the "Jermaine Jackson" article that is missing the "Quick translation" indicator, although its lead section size falls in the "easy" size range (1000 < lead section = 3521 < 4000). This happens because instead of the lead section size, the article size is taken into account, which falls in the "medium" range (10000 < article size = 38845 < 40000). Moving this task back to "In-progress"

We currently display proper publishing options on desktop both for missing sections ("New section", "Sandbox") and for present sections ("New section", "Sandbox", "Expand", "Replace"), as demonstrated in the following screencast from production el wiki:

@GMikesell-WMF thank you for all the work! I watched your screencasts for the failed test cases, and I feel that both of them should be considered successful.

This task is a prerequisite for supporting T388503 on desktop.

There is no database table left unused even after the latest changes, as we still follow the old way of fetching and storing suggestions, the difference is that we only store/fetch favorite suggestions now and no other type of suggestions is supported. That means we still rely on both cx_lists and cx_suggestions database tables. Of course, there is no longer need for two tables, but that would require the creation of a new table (cx_favorite_suggestions) and some data migration to avoid losing existing favorites. Then, we could drop cx_lists and cx_suggestions tables. If this is something we want to do, I can create a task about it.