This is an attempt to fix the issue: https://github.com/FriendsOfSymfony/FOSElasticaBundle/issues/526
It will cause a significant slowdown in a large batch, but it appears to be the only way to prevent an exception from bubbling up during a normal use case.
This probably isn't the best way to solve my problem,
but the issue is this.
Step 1: Create a new doctrine entity for which it's `is_indexable_callback`
returns false. When doctrine flushes this entity to the database,
elastia will not index it with elastic search. (Correct)
Step 2: Update your doctrine entity and change some fields so
that `is_indexable_callback` _still_ returns false. Persist and flush
to the database.
At this point, the postUpdate listener on ElastiaBundle is called
and since the `is_indexable_callback` returns false, it believes
it needs to remove it from the elastic search index and queues it
for deletion. The deletion of course fails because it was never there
in the first place.
This solution simply ignores failures from deletions in the index.
Perhaps a better solution would be to have a smarter listener
that could determine if the entity was previously present in the
elastic search index or not, but that would require significant
refactoring.
Addresses issues discuseed in #284
Credit to @bbeaulant for simple solution. Opening a PR to
discuss more generally.
