{"record":{"id":"58317cbdeb26313e","repo":"quickwit-oss/tantivy","slug":"failed-to-downcast-collector-fruit","errorCode":null,"errorMessage":"Failed to downcast collector fruit.","messagePattern":"Failed to downcast collector fruit\\.","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"error","filePath":"src/collector/multi_collector.rs","lineNumber":120,"sourceCode":"}\n\n/// FruitHandle stores reference to the corresponding collector inside MultiCollector\npub struct FruitHandle<TFruit: Fruit> {\n    pos: usize,\n    _phantom: PhantomData<TFruit>,\n}\n\nimpl<TFruit: Fruit> FruitHandle<TFruit> {\n    /// Extract a typed fruit off a multifruit.\n    ///\n    /// This function involves downcasting and can panic if the multifruit was\n    /// created using faulty code.\n    pub fn extract(self, fruits: &mut MultiFruit) -> TFruit {\n        let boxed_fruit = fruits.sub_fruits[self.pos].take().expect(\"\");\n        *boxed_fruit\n            .downcast::<TFruit>()\n            .map_err(|_| ())\n            .expect(\"Failed to downcast collector fruit.\")\n    }\n}\n\n/// Multicollector makes it possible to collect on more than one collector.\n/// It should only be used for use cases where the Collector types is unknown\n/// at compile time.\n///\n/// If the type of the collectors is known, you can just group yours collectors\n/// in a tuple. See the\n/// [Combining several collectors section of the collector\n/// documentation](./index.html#combining-several-collectors).\n///\n/// ```rust\n/// use tantivy::collector::{Count, TopDocs, MultiCollector};\n/// use tantivy::query::QueryParser;\n/// use tantivy::schema::{Schema, TEXT};\n/// use tantivy::{doc, Index};\n///","sourceCodeStart":102,"sourceCodeEnd":138,"githubUrl":"https://github.com/quickwit-oss/tantivy/blob/b5d8deb80c26924e6b007a5b1a7630f35ca64de4/src/collector/multi_collector.rs#L102-L138","documentation":"Fires in FruitHandle::extract when the boxed fruit at this handle's position in MultiFruit cannot be downcast to the requested TFruit type. Each handle is handed out by MultiCollector next to a collector whose fruit type it matches, so a mismatch means the caller is extracting with a fruit type that differs from the collector the handle was created for, or handles are mixed between two MultiCollector runs. The doc comment explicitly notes it can panic on faulty code.","triggerScenarios":"Thrown at src/collector/multi_collector.rs:120 when the library encounters an invalid state.","commonSituations":"See trigger scenarios.","solutions":["Extract each fruit with exactly the fruit type of the collector at the handle's position","Do not reuse FruitHandle values across different MultiCollector executions","Prefer using the tuple-collector API where fruit types are checked at compile time"],"exampleFix":null,"handlingStrategy":"type-guard","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":[],"tags":[],"backgroundTag":null,"analyzedSha":"b5d8deb80c26924e6b007a5b1a7630f35ca64de4","analyzedAt":"2026-09-05T13:20:51.521Z","contentChangedAt":"2026-09-05T13:20:51.521Z","schemaVersion":2},"datasetVersion":"2026-09-12T17:17:11.597Z"}