If you write a Smart Search plugin that creates a taxonomy (content map) that includes non-disjoint nodes (shown under "Titles" in the admin UI) then you will sometimes get pages in the search results which have fewer entries than expected. For example, if a page should have 20 results in it, it might only have 19. There are no results missing from the search, but the pagination is a bit off.

All the core content types (eg. Articles, Contacts, etc.) have taxonomies with disjoint nodes so the bug doesn't manifest itself with any of the core components. You'd have to write your own plugin to experience the problem. I'm not going to do that here as I'm hoping that my description of the problem and the simplicity of the solution will suffice.

Suppose you have a database table and you want to write a simple plugin to index its contents. Apart from the usual text entries, you also want to have a taxonomy (content map) called "Flags" which indicate some particular features of some of the items in the table. These flags are not disjoint, so a particular item could have more than one flag associated with it.

In the plugin, the code might look something like this (not real PHP, of course):

if ($item has A)
{
    $item->addTaxonomy('Flags', 'A');
}

if ($item has B)
{
    $item->addTaxonomy('Flags', 'B');
}

The Smart Search indexer can and does correctly handle the case where some items have both A and B. The only problem is that front-end search results pagination is off whenever the page contains an item that has both flags.

In components/com_finder/models/search.php you can see the cause of the problem. The FinderModelSearch::getListQuery method returns duplicate results in this case because the WHERE clause associated with the taxonomy does a WHERE t0.node_id IN (x,y) which logically ORs the x and y nodes, but also results in separate (duplicate) rows for each. However, FinderModelSearch::getResultsData squashes the duplicates out because it does a loadObjectList('link_id'). So if the raw database query returned 20 results, say, after squashing duplicates the page actually returned to the user might contain only 19 (or fewer).

The fix is simply to avoid getting duplicates in the first place. Simply add a DISTINCT to the SELECT in getListQuery.