Exactness does not match correctly in presence of hard separators

[dureuill]

Describe the bug

When a query contains a hard separator like Batman: the dark knight returns, part 1, then documents with the title Batman: the dark knight returns, part 1 are not matched with the strategy MatchesFull, while they should.

This is due to multiple factors

• hard separators are not given a correct position when parsing queries
• the field_id_word_count_docids stores only the word count up to 10.
• the field_id_word_count_docids stores the max position instead of the number of words. This max position takes into account the offset of hard separators and so we easily get higher than 10.

To Reproduce
Steps to reproduce the behavior:

1. Use meilisearch from Add normalized and detailed scores to documents returned by a query #3821
2. Index movies
3. Query Batman: the dark knight returns, part 1 with ranking score details enabled
4. Notice that the match is matchesStart or noExactMatch instead of fullMatch

Expected behavior
Exactness matches fullMatch in this case

Meilisearch version:
v1.1.1, v1.2

[curquiza]

Hello @dureuill
Thanks for the report and the bug fix 🙏
Is this bug present in v1.2? My question behind: should we add it to the v1.3 changelogs as a bug fix?

Also, I recommend avoiding writing main as Meilisearch version -> when we read the issue in the future, main does not have the same meaning as now.
The best is a version, or at least a commit sha (and precise if we are between v1.2 and v1.3 sprint)

[dureuill]

Is this bug present in v1.2? My question behind: should we add it to the v1.3 changelogs as a bug fix?

Yes, and also in v1.1 and earlier in some shape

Also, I recommend avoiding writing main as Meilisearch version -> when we read the issue in the future, main does not have the same meaning as now.

Duly noted, thanks I'll edit