apache / apache/lucene

Start offset going backwards has a legitimate purpose [LUCENE-8776]

Open
#9,820 41 comments 0 reactions 0 assignees View on GitHub
affects-version:7.6 legacy-jira-priority:Major module:core/search type:bug
Dominant language
Java
Stars
3.6k
Forks
1.4k
Avg merge
2d 11h
Merged PRs (30d)
88

Description

Here is the use case where startOffset can go backwards:

Say there is a line "Organic light-emitting-diode glows", and I want to run span queries and highlight them properly. 

During index time, light-emitting-diode is split into three words, which allows me to search for 'light', 'emitting' and 'diode' individually. The three words occupy adjacent positions in the index, as 'light' adjacent to 'emitting' and 'light' at a distance of two words from 'diode' need to match this word. So, the order of words after splitting are: Organic, light, emitting, diode, glows. 

But, I also want to search for 'organic' being adjacent to 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'. 

The way I solved this was to also generate 'light-emitting-diode' at two positions: (a) In the same position as 'light' and (b) in the same position as 'glows', like below:

|organic|light|emitting|diode|glows|
|-|-|-|-|-|
| |light-emitting-diode| |light-emitting-diode| |
|0|1|2|3|4|

The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets are obviously the same. This works beautifully in Lucene 5.x in both searching and highlighting with span queries. 

But when I try this in Lucene 7.6, it hits the condition "Offsets must not go backwards" at DefaultIndexingChain:818. This IllegalArgumentException is being thrown without any comments on why this check is needed. As I explained above, startOffset going backwards is perfectly valid, to deal with word splitting and span operations on these specialized use cases. On the other hand, it is not clear what value is added by this check and which highlighter code is affected by offsets going backwards. This same check is done at BaseTokenStreamTestCase:245. 

I see others talk about how this check found bugs in WordDelimiter etc. but it also prevents legitimate use cases. Can this check be removed?

---
Migrated from [LUCENE-8776](https://issues.apache.org/jira/browse/LUCENE-8776) by Ram Venkat, updated Oct 26 2021
Attachments: [LUCENE-8776-proof-of-concept.patch](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-8776/LUCENE-8776-proof-of-concept.patch)

Contributor guide

Open the contributing guide

Research direction

Start at DefaultIndexingChain:818 and BaseTokenStreamTestCase:245, then read the discussion and the LUCENE-8776-proof-of-concept.patch. Reproduce the span-query and highlighting use case described in the issue and determine which checks or highlighter behavior must change. Done means legitimate backwards start offsets work without regressing the existing validation cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
search
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.