Hello all, we are using ts server of v0.24.1 and w...
# community-help
a
Hello all, we are using ts server of v0.24.1 and we get this problem: we are trying to search for a single document in the collection using this filter: uri:rade/aols/insolvenzrecht/persoenliche-risiken-fuer-organe-von-kapitalgesellschaften-gmbh-geschaeftsfuehrer-ag-vorstand the document is there, but the /search endpoint responds with 404. It seems that the issue is the filtering value too long. So my questions are • what is the current limitation on the filtering value length? • how we can overcome this problem with lowest effort?
j
It’s most likely a URL encoding issue. The GET endpoint support upto 2K characters. In any case, if you expect long strings and to rule out any URL encoding issues, I’d recommend switching to the multi_search endpoint which uses POST and JSON and doesn’t have size limitations
a
Hi, thank you for your response. Just checked, it seems it is not the URL encoding issue this is the uri value i'm searching for(and the document does contain it) rade/aols/insolvenzrecht/persoenliche-risiken-fuer-organe-von-kapitalgesellschaften-gmbh-geschaeftsfuehrer-ag-vorstand this filter returns nothing: uri:rade/aols/insolvenzrecht/persoenliche-risiken-fuer-organe-von-kapitalgesellschaften-gmbh-geschaeftsfu and this filter(1 symbol shorter) returns the document: uri:rade/aols/insolvenzrecht/persoenliche-risiken-fuer-organe-von-kapitalgesellschaften-gmbh-geschaeftsf
The length of the filter value that still produces results is exactly 100 symbols. Does Not seem like a coincidence
🤔 1
Could you pls take a look at this case? It produces quite a bad bug on our side....
j
Hmm that does sound strange. Could you give me a snippet like this with your schema and some sample data: https://gist.github.com/jasonbosco/7c3432713216c378472f13e72246f46b that replicates the issue?
a
Ok, i'll try
I was able to reproduce it on the new collection
1 min
ts_error.txt
here you go
"version": "0.24.1"
Sorry to bother you @Jason Bosco, could you pls tell me if you are looking this problem and if i could count on a new version of a server within next few days? We need to decide on our side what to do with the bug...
No pressure though)))
j
This sounds very similar to this issue although that was in the query parameter. In any case, could you try upgrading to
0.25.0.rc46
to see if that fixes the issue?
a
ok, i'll try
j
If that doesn’t work either, could you convert this snippet to a set of curl commands?
a
Ok
Thank you
Can you pls provide the link? I tried this wget https://dl.typesense.org/releases/0.25.0.rc46/typesense-server-0.25.0.rc46-linux-amd64.tar.gz but it returns 404
a
ok thanks
Ok, it did not work out...0.25.0.rc46 still returns 404. Here is the sh file:
ts_search_error.sh
j
Ok we’ll take a look and let you know in about 24 hours… Hard to give an ETA at this time, depending on the complexity of the fix
a
Thank you, i'll be waiting for the fix
j
I just noticed in your snippet that
token_separators
is empty. Could you move the characters under
symbols_to_index
to
token_separators
?
a
ts_search_error.sh
k
We have been able to reproduce. Will update once we have a fix.
We limit tokens to a maximum of 100 characters. Since
symbols_to_index
is used that long
uri
is treated as a single word. This gets truncated during indexing but not during filtering query, and so it doesn't fetch expected results. We will have a fix for this tomorrow.
a
Thank you @Kishore Nallan!
k
@Anton Khatunzev I've just published the
0.25.0.rc48
DEB. Can you please try against that? ``````
a
Hi, thank you, i'll check today
Hi @Kishore Nallan the problem is solved it seems. Thank you!
k
Glad to hear