Deleted files won't be cleared out of future searches

[ejucovy]

I haven't verified this but I'm pretty sure that, as implemented, the SQLIndexer search backend will never clear the contents of deleted files from its cache. Instead, a deleted file's last contents before deletion will persist in the cache and therefore in the visible search results.

I think it's sufficient to implement this as a side effect of #9790 -- by adding the extra data described there about files added/removed/changed, the reindex_repository method can be responsible for silently clearing out deleted contents as well.

[ejucovy]

This does indeed seem to be a problem. It actually causes errors ("No node ...") when the search results return a hit for a file that no longer exists.

[robert.keizer@…]

Hit this today using Trac 1.0.1.

Will have to disable the plugin and hope to find a replacement while this gets patched.

[ejucovy]

I'll try to look into this over the next week.

A patch would be welcome though!

[ejucovy]

Replying to ejucovy:

I think it's sufficient to implement this as a side effect of #9790 -- by adding the extra data described there about files added/removed/changed, the reindex_repository method can be responsible for silently clearing out deleted contents as well.

I've changed my mind about this; I don't think it's sufficient to just fix #9790. The core multireposearch framework should be designed to not trust the search backend. Any errors should be logged and ignored, so that the end user's system doesn't explode altogether if a search backend is implemented incorrectly. Tickets #10792 and #10793 are other cases where the same approach needs to be used.

Fixed in ​https://github.com/boldprogressives/trac-MultiRepoSearchPlugin/commit/148a9ccb95d1d09ab83990fd5443ad09c5ff0285 and ​https://github.com/boldprogressives/trac-MultiRepoSearchPlugin/commit/67fd940b3ed67d313a825affde6c846be297d874

I'll tag and release a new version 0.4 with this fix.