This was a recent issue with an app we recently deployed, but was fixed once Pat made a small enhancement to the way destroys work for TS.

Previously, when using suspended_delta, TS would not remove destroyed objects from the delta index but would instead try to do it after the suspended_delta block call. This did not work because the suspended_delta call did not keep track of the documents to remove, and although a delta index would fix this, if using delayed_job this could possibly be a while away.

Pat has since changed the behavior of destroys to always remove the document from the delta index, since then I have not had this issue.

I never knew of retry_stale, thanks for the tip, it may come in handy if the problem pops up it ugly head again.

Thanks for the post