Bugfix reindex! when all of targeted records are to delete and nothing to save #452
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem is this fixing?
How to reproduce
app/models/product.rb
in rails console for instance
Got the error below
Cause
This error happens because I'm using conditional index.
In
reindex!
, if any records to be deleted, it deletes from algolia and remove from activerecord target.algoliasearch-rails/lib/algoliasearch-rails.rb
Line 453 in f8f599d
And then the rest of activerecord target to be saved.
algoliasearch-rails/lib/algoliasearch-rails.rb
Line 464 in f8f599d
But when all of the activerecord target to be deleted, there is nothing to be saved. Thus
AlgoliaSearch.client.save_objects(index_name, objects)
returns empty array. And then.last
gotnil
,.task_id
gotundefined method
.Describe your change
I just added&.
to calltask_id
. Sorry, I have no idea if I could use&.
operator considering supported ruby version.UPDATED: Since I reflected it's not good to use
&.
, I have addedpresent?
check on return value ofsave_objects
explicitly. be4ee11When saving objects is empty, it seems there is no reason to wait task. So with using
present?
check, settinglast_task
asnil
seems good enough to handle this case.But I'm not so sure if it should wait
delete_objects
task. However, I think it doesn't break existing behavior with this change at least.