You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MetaFieldRanker ignores missing_meta="drop" when meta values can't be sorted #13230
Describe the bug MetaFieldRanker with missing_meta="drop" still returns documents that don't have the meta field, if the other documents have values that can't be sorted together.
Error message
No error. The ranker logs these warnings and then returns the document anyway:
... the Documents with IDs 3 don't have this meta key.
Because the parameter <missing_meta> is set to 'drop', these Documents will be removed from the list of retrieved Documents.
Tried to sort Documents with IDs 1,2, but got TypeError with the message: '<' not supported between instances of 'int' and 'str'
Expected behavior
Documents without the meta field are dropped. The example below should print ['1', '2'].
Additional context
When sorting fails, run() returns deduplicated_documents[:top_k], which includes the documents without the field:
This is not the case from #12952 (no document has the field), which is fixed. Here some documents have the field, but their values can't be sorted together.
Hi! I'd like to help with this issue if it hasn't been picked up yet.
My plan is to reproduce the behavior, add regression tests for missing metadata combined with incomparable metadata values, and then make the smallest change needed to ensure missing_meta="drop" is respected.
Would this be a suitable contribution to take up? Please let me know if there's a preferred approach. Thanks!
Activity
aawhan0 commentedon Oct 12, 2026
Hi! I'd like to help with this issue if it hasn't been picked up yet.
My plan is to reproduce the behavior, add regression tests for missing metadata combined with incomparable metadata values, and then make the smallest change needed to ensure missing_meta="drop" is respected.
Would this be a suitable contribution to take up? Please let me know if there's a preferred approach. Thanks!
yuv009 commentedon Oct 12, 2026
Hi @aawhan0, I've already opened #13231 for this.