Done
Details
Assignee
Lora WoodfordLora WoodfordReporter
Jason LoefflerJason LoefflerPriority
CriticalHarvest Time Tracking
Open Harvest Time Tracking
Details
Details
Assignee
Lora Woodford
Lora WoodfordReporter
Jason Loeffler
Jason LoefflerPriority
Harvest Time Tracking
Open Harvest Time Tracking
Created August 22, 2017 at 6:30 PM
Updated March 17, 2020 at 2:05 PM
Resolved March 17, 2020 at 2:03 PM
Filing this as a feature request and not a bug, since it's an issue with a known workaround.
Having just upgraded from 1.5.1 to 2.1.1 on our test instance, we're seeing the following:
Perform upgrade tasks as described in docs
Delete all files under indexer_state/
Start application
Application begins adding records to index by repository numeric order
When application reaches the end of one of our repositories (in our case, repositories/7, log helpfully reports:
Indexer then starts over with repository 7, throws an error upon completion, restarts indexing, and so on.
From what I can tell, the indexer gets hung up on orphaned records. The workaround is to identify orphaned records with db queries, then remove the orphaned records with API calls. Following that, the indexer can proceed.
Is there a way to more gracefully handle orphaned records to that they don't interfere with indexing?