Search in Set/Collection: results disappear while typing and reappear while typing further

What’s The Bug?

I know, there are already some bug reports about problems with search.
But there are different bugs in global search, as well as in search in Set/Collection.

In the attempt to bring more light into that chaos, I try now to isolate the particular bugs; one BR for one specific bug.
– This specific bug report is only about search in Set/Collection and only about diasapearing results during typing the search term.
(Edit: the same bug happens also in global search, see next post)

How To Reproduce It

As you see in my videos, search results disappear during writing the search term. But they reappear while typing further.
It happens in the Grid, as well as in the Gallery.
– It doesn’t happen always; I wasn’t able to find a pattern. Sometimes I thought that non alphabetical characters often “trigger” the bug. But as you see in one of the videos, it also happens with normal terms like “Karpaltunnelsyndrom”.

Image or Video


The Expected Behavior

Search should find the term that I enter into the search field. :wink:

Additional Context

As mentioned, there are some other bugs with search; I’ll write separate bug reports for them over time, each as specific as possible.

Device

Desktop PC

OS

Win 10

Anytype Version

0.44.0

Network Mode

AnySync

Technical Information

OS version: win32 x64 10.0.19045
App version: 0.44.0
Build number: build on 2024-12-16 16:53:50 +0000 UTC at #c04d64d52304c0fe8800032e74e49a7159abdbad (dirty)
Library version: v0.38.7
Anytype Identity: AAtt6aReARByswg2CbvZhveoJEEcnydfDu7U2VAkgJALsE7D
Analytics ID: 8a514008-4f5d-40d3-970f-a0d241b63af2
Device ID: 12D3KooWGqd6JSafCCcEwvnke5JAVgBNnuR9gGQeSBQ5HdUboWtG

Now I was able to catch the same error also in global search (not only in Set/Collection):

This report has been added to our issue tracker and received by the Development Team.

Das ist ein guter Fund!

This is how the stemmer works:
The word ‘detective’ is stored as ‘detect’ after the FTS normalization process is applied.

Queries like ‘d,’ ‘de,’ ‘det,’ ‘dete,’ ‘detec,’ and ‘detects’ are prefixes of ‘detect.’

However, ‘detecti’ is not an English word, so in the query, it appears as ‘detecti.’ (stemmer can’t normalise it)
But ‘detecti’ is not a prefix of ‘detect.’

This is where things go wrong, but unfortunately, nothing can be done about it.

I experience the problem all the time. Even with much shorter words.
If this ominous “stemmer” doesn’t do the job well, it should become replaced, in my humble opinion.

I expect (and I think I speak for everyone here), that Search works character for character - and this in every language and also including special characters (for example !?=&$ etc) and even for smileys like :mushroom::grey_exclamation::question::exclamation::warning::man_student::clapper::apple::banana::heavy_check_mark::heavy_plus_sign::arrow_forward::calendar::musical_note::hammer_and_wrench:!

We will work on it. You can check out how it works here:

However, it is always a tradeoff. And this is the way how fts search engines work.

Not surprisingly I stumbled upon the same bug in the search in the sidebar when I was searching for a relation.

search-not-working-correctly

Maybe an idea is to use a second search engine that finds objects as described here. I want to rely on the search to find my stuff even if it takes longer.