Aborted save with transaction rollback should not add to index

[adamthehutt]

When a model save is wrapped in a transaction that is rolled back, the model is still added to the searchable index, even though it doesn't actually exist in the database. Unfortunately I don't know enough about the innards of Scout to suggest a fix, but presumably it needs to delay queueing the job until it's certain that the save has been committed. (All of this also applies to updates.)

An added benefit of fixing this, for those using DatabaseTransactions in unit tests, is that it would solve issue #34 as well.

[jitendra-1217]

@adamthehutt : Did you find any solutions (or workaround) it?

[adamthehutt]

@jitendra-1217 No. It's a complicated issue to solve. It's possible that the best solution would be to link the Queue actions to any surrounding DB transaction. If the transaction rolls back, the queued jobs are dropped. If it is committed, the jobs are passed to the queue runner. Personally I can't imagine a situation where that wouldn't be the desired behavior, but it would break BC.

[adamthehutt]

There are other references to this problem (not having to do with Scout). No one seems to have a good workaround or solution. I think it's a general Laravel issue that needs to be addressed.

https://laracasts.com/discuss/channels/general-discussion/queues-within-db-transactions
http://stackoverflow.com/questions/35764150/combining-transactions-with-queues-in-laravel

There may be a solution involving job events but the docs aren't very clear.

[joshforbes]

I think I have a related problem:

In an app I am working on there is a fairly long company registration process (persists about 8 records). This process is wrapped in a transaction. The first record that has to be created is searchable. When this object is created it fires off the scout queue job. When the scout queue job serializes models, the transaction sometimes has not yet been committed. Meaning that $this->models will be empty and no record will get indexed.

I agree that it is more of a Laravel issue. I would think the ideal solution would be that create/save events should not be fired off until a transaction is committed. But I assume this is either difficult or there is a reason it is this way.

[mhd21]

https://github.com/fntneves/laravel-transactional-events

[driesvints]

Going to close this as this is more of a Laravel issue then it is a Scout issue as mentioned above.