Meilisearch & global search

[beNjiox]

• Laravel Version: 10.39
• Nova Version: 4.32.11
• PHP Version: 8.3.1
• Database Driver & Version: Postgresql 12
• Operating System and Version: Mac Os M2 (Somona)
• Browser type and version: Arc
• Reproduction Repository: https://github.com/###/###
• Meilisearch : "meilisearch/meilisearch-php": "^1.5"

Description:

I'm having an issue with the results displayed on the global search when using scout with meilisearch. I have an index "orders" which contains a "public id" of format XXXXX-XXXXX-XXXXX.
When I type an order id, I don't get the results in the order it should be. The issue is not present when searching for the same order in the index views of the resource.

When digging in the SQL query made to be used, the IDs of the rows in the DB are in the correct order. It just get reordered incorrectly.

This looks like a bug that already existed with Algolia: laravel/scout#369.

When searching for the term direct on Meilisearch, it's ordered correctly

Basically, I believe that there's some sort of reordering for the global search that override the original sorting. While trying to dig in the source, I saw the order being "killed" here : vendor/laravel/scout/src/Engines/MeilisearchEngine.php:282 (map method).

Here you can see, the IDs are different than the one expected. I have nothing in my resource class that could override the ordering.

Hope this is clear enough, happy to help futher if needed

Detailed steps to reproduce the issue on a fresh Nova installation:

[beNjiox]

By digging further myself, I believe I found the issue.

When queryScoutModelsByIds(Builder $builder, array $ids) is being invoked with a list of IDs, there's a limit being done in the query

        $query = static::usesSoftDelete()
            ? $this->withTrashed() : $this->newQuery();

        if ($builder->queryCallback) {
            call_user_func($builder->queryCallback, $query); // <-- this adds a LIMIT 5
        }

        $whereIn = in_array($this->getScoutKeyType(), ['int', 'integer']) ?
            'whereIntegerInRaw' :
            'whereIn';

        return $query->{$whereIn}(
            $this->qualifyColumn($this->getScoutKeyName()), $ids
        );

The problem is that the result of the query does not contain the most relevant record (in my use case, the query returns 11 records.)

Thus, when the code tries to reorder the results by position, it doesn't work since the original record is not present.

To account for this, If in my resource, I set up

    public static $globalSearchResults = 11;

I see my most relevant record being first, but this is not ideal as it would take a lot of room.

---

Not sure how this can be fixed, but I hope it will give you ideas.
One way to do it is to not limit the results, but only the display, but that may imply performance concern, I suppose.

[beNjiox]

Moving on about this - I solved my issue by setting the same value for $scoutSearchResults and globalSearchResults.

I've done so in the boot method of the NovaServiceProvider

Resource::$scoutSearchResults = 5;
Resource::$globalSearchResults = 5;

By doing this, we limit the "hits per page" from the engine with the same value of the limit used in the SQL request done by Scout to get the underlying eloquent models.
By doing so, there's no results being lost during the where in.

This works well and I can see now the relevant results in my global search.