Laravel Scout with Algolia sending wrong objectID on delete

I have a Laravel project with a forum using Scout to interact with Algolia and index threads that are created. Part of the Thread model is below. I did not override the Scout key or key name.

class Thread extends Model
{
    use HasFactory, Searchable;

    protected static function booted() {
        static::created(function ($thread) {
            $thread->update(['slug' => $thread->title]);
        });
    }

        /**
     * Get the indexable data array for the model.
     *
     * @return array<string, mixed>
     */
    public function toSearchableArray(): array
    {
        $array = [
            'title' => $this->title,
            'slug' => $this->slug,
        ];

        return $array;
    }

When I create a thread everything works as expected, but when I delete a thread using the below code, the thread is not deleted from the Algolia index.

$thread->delete();

I did some digging on Algolia API requests, and I think I've figured out what is going wrong. Here you can see the API request when a thread is created, and the subsequent request when that same thread is being deleted.

Created:

{
  "requests": [
    {
      "action": "updateObject",
      "body": {
        "title": "Test thread",
        "slug": "7-test-thread",
        "objectID": 7
      }
    }
  ]
}

Deleted:

{
  "requests": [
    {
      "action": "deleteObject",
      "body": {
        "objectID": "-7"
      }
    }
  ]
}

You can see for the API request to delete the object, the object id is "-7" instead of "7". I've tried to search everywhere through the Scout classes, but I cannot figure out why the dash is being prefixed onto the objectID when I go to delete the model. Does anyone have any ideas as to what might be causing this?

Thanks!

LaryAI

2 years ago

Level 58

It seems like there might be an issue with how the objectID is being determined when the delete operation is being called. The objectID should match the one that was used when the object was indexed. In Laravel Scout, the objectID is typically the primary key of the model unless you've customized the getScoutKey method.

Here's what you can do to troubleshoot and potentially fix the issue:

Ensure that the getScoutKey method on your Thread model is returning the correct key. If you haven't defined this method, Scout will use the primary key of the model by default.

/**
 * Get the value used to index the model.
 *
 * @return mixed
 */
public function getScoutKey()
{
    return $this->getKey();
}

If you have overridden the getScoutKeyName method, make sure it is returning the correct key name, which should be the primary key column name.

/**
 * Get the key name used by Scout to index the model.
 *
 * @return string
 */
public function getScoutKeyName()
{
    return $this->getKeyName();
}

Check if there are any global scopes or local scopes applied to the Thread model that might be altering the ID when the model is being deleted.
If you are using model events (like creating, updating, deleting, etc.), ensure that none of these events are modifying the ID in a way that could cause this issue.
If you have any accessors or mutators on the Thread model that modify the ID, ensure they are not being called in a way that affects the deletion process.
Finally, if none of the above steps resolve the issue, you can try to manually set the objectID before deleting the model to ensure it matches the ID used when the model was indexed:

$thread->scoutMetadata(['objectID' => $thread->getScoutKey()]);
$thread->delete();

If after trying these steps the issue persists, it might be helpful to look into the Scout source code or reach out to the Scout community for further assistance. There might be a bug or a specific configuration issue that's causing the objectID to be altered during deletion.

Please or to participate in this conversation.