Scout won't return correct model `->keys()` when using custom `searchableAttributes` from Meilisearch

[flexchar]

• Scout Version: 9.4.10
• Scout Driver: MeiliSearch
• Laravel Version: 9.27.0
• PHP Version: 8.1.8
• Meilisearch CLI Version (If using Meilisearch): 0.28.1

Description:

I've discovered that Searchable::search('query terms')->keys(); fails when customizing searchableAttributes by Meilisearch.

Let's say you have comments blog that contains more than just message body. You want to only search based on its contents so you only list those attributes. Doing so will force Meilisearch to return raw results in different order. Below is the snippet of Searchable::serach()->raw(). Notice how 'id` is no longer the first element in the array.

array:7 [
  "hits" => array:20 [
    0 => array:11 [
      "body" => "Lorem Ipsum blabla"
      "translation" => ""
      "id" => 42769
      "media_id" => 111
      "conversation_id" => 19
      "language" => null
      "user_id" => 1
      "visibility" => 3
    ]
    1 => array:11 [
      "body" => "Lorem Ipsum blabla"
      "translation" => ""
      "id" => 44648
      "media_id" => 258
      "conversation_id" => 31
      "language" => null
      "user_id" => 1
      "visibility" => 3
    ]
 ],
  "estimatedTotalHits" => 96
  "query" => "blabla"
  "limit" => 20
  "offset" => 0
  "processingTimeMs" => 3
  "nbHits" => 96
]

As such it forces the following code to break search: https://github.com/laravel/scout/blob/48aeabdd80763708ac704f6053f7b83e222fe007/src/Engines/MeiliSearchEngine.php#L219.

Maybe we could use ->mapIdsFrom(string $key) and pass ->getScoutKeyName() into?

Steps To Reproduce:

I hope I explained well. If not, please ping me and I will set up a repo.

[driesvints]

Thanks @flexchar. @mmachatschek I'm not sure it was intended that Scout supported this? The related PR does look good though.

[mmachatschek]

@driesvints the response seems legit, BUT I think @curquiza mentioned somewhere, that the search response will return the primaryKey as the first element in the search payload of the document.

@curquiza did this recently change? I do remember to have tested this a few times were the primaryKey was the first element in the payload

[curquiza]

Hello everyone! 👋 No, as far as I know, we haven't changed anything...

However, I don't think getting the first() element of the object is a good solution either. Indeed, Meilisearch returns a JSON response, and even if Meilisearch tries to keep the order of the document's fields as much as possible, it cannot be guaranteed by definition of objects in JSON. It's the same for any HTTP server returning JSON: you cannot rely on the order of the returned fields in the objects.

But yes, in any case, we haven't changed anything in this part in Meilisearch v0.28.1 as far as I know.

I would love to know in which context you got this change: did you only update searchableAttributes? Did you use another version of Meilisearch before (like v0.27.0) and did it work?

[driesvints]

Thanks all, we've gone ahead and merged a fix but feel free to discuss further if you wish.