Hey there,
I'll explain my use case first.
- I'm trying to index just the title field on a new site to test out search_api.
- I have a few problematic webform nodes in my site that made their way into the system over the course of development.
- I try to let the system index titles from every node type
- I run cron and get an error at the search_api_index_specific_items function in search_api.module when it tries to clone an item that isn't an object (it's just the nid of the dodgy webform node, no idea why)
- I change the search index to ignore the webform content type
- I rerun cron and get the same error
- I disable and uninstall search_api
- I reenable and recreate, this time with the restriction before running cron
- Same error occurs
- I trace the error back to the queue table, there's a bunch of stuff queued up there for indexing with the name "search_api_indexing_queue"
- I disable and uninstall the module again, check the queue table and those queue items with "search_api_indexing_queue" are still in there
- I manually remove those entries from the queue, reinstall and everything works fine
SO I propose we add a few lines to the uninstall hook implementation.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2052701-3--remove_queue_on_disable.patch | 371 bytes | drunken monkey |
| #1 | clean_queue-2052701-1.patch | 520 bytes | er_d0s |
Comments
Comment #1
er_d0s commentedHere's my patch
Comment #2
er_d0s commentedComment #3
drunken monkeyYou're right, thanks for reporting and providing a patch!
However, I think the queue should already be cleared when disabling the module, not only when uninstalling. After all, we also clear all items tables, and completely restart tracking and indexing once the module is re-enabled. Still leaving items in the queue would be a bit weird therefore, I'd say.
So, revised patch attached. Please varify that it also fixes your problem!
Comment #4
er_d0s commentedGlad to help!
It's a tricky one to replicate because I'm not actually sure how I got the broken nodes (I suspect something to do with UUID features and moving stuff around), nor am I aware of what caused the queue to get clumped up. Regardless the patch's actions are very passive and I can't think of any possible scenario where they could be destructive to a site.
Comment #5
drunken monkeyWell, it would have been sufficient to just see whether the queue items get properly deleted. But if that's not easily possible, don't worry, I'll just wait a few days whether someone else wants to review this patch and then commit it. (And then I'll finally have an erdos number of 1 …)
Comment #6
drunken monkeyCommitted.