Hi <@U01PL2YSG8L>, i just checked your answer unde...
# community-help
a
Hi @Kishore Nallan, i just checked your answer under https://github.com/typesense/typesense/issues/329 is there documentation or any examples for this feature available?
k
Sorry, let me post a comment to that issue.
a
And one more question: i do need to install v0.22.0 server to use this feature, correct? If it is so, where or when can i get it?
k
Yes, Linux binary is fine?
I've updated my comment on that issue with usage instructions.
a
yes, i need the linux binary
k
Download here:
Copy code
<https://dl.typesense.org/releases/0.22.0.rcs10/typesense-server-0.22.0.rcs10-linux-amd64.tar.gz>
a
thank you!
šŸ‘ 1
hello Kishore, i have couple updates: 1. Geosearch seems to be working fine and fast. I had no time to debug it properly though... 2. With v.0.22.0 server i got that bad issue when indexing documents(using upsert). We have a lot of documents(about 75k) in our db that needs to be imported into TS. Documents themselves are pretty big. In my current scenario they contain a lot of text and some big non-indexed json fields. We import these documents in batches(5k records in a batch). At the end of the import of the each batch i analyze the response returned by TS client. And it appeared that when i sent 5k records payload, i got back response containning ~4.8k "ImportDocumentResponse" objects. No errors. So my code throws an exception at this stage. I decided to check if this happens on a smaller batches. And it did. I got the same problem on 2k records batch: 2k documents sent, 1996 ImportDocumentResponse items back. So i also decided to check if documents in the tail of the payload are really missing in the TS collection. And it seems that they are there(they do exist on TS side)! Very weird...Also, i need to mention that some time ago i had a problem with similar symptoms. I was able to solve it by setting ConnectionTimeout setting to 0 for my TS client. But now i'm a bit lost... i will try to find more precise testcase... But for now just letting you know that v0.22.0 behaves differently during the import...
k
@Anton Khatunzev We've made the import atomic in 0.22.0 -- earlier it is possible that if your connection times out mid-way, imports could end mid way too. However, with 0.22.0 the entire response body is first buffered and then only indexing begins, so it is atomic.
Can you please try using curl and see if you find a similar mismatch in response?
a
@Kishore Nallan Hi, yes, i think i will have to... As i said, the payloads are quite big, so i'll try to find more precise testcase first
hello @Kishore Nallan
i got the testcase
tried it with 3k batch using curl. And i got 2997 items in the response
it happens from time to time
would it be possible to do the screenshare?
k
Oh cool, is it possible to share that dataset with me?
a
yes
but it is 100M jsonl. How would you like to get it?
can we do a screenshare maybe? so you can see the problem?
k
Do you have a public s3 bucket I can download from? You can encrypt with my gpg ID.
I can do a screenshare in 30 mins.
a
ok, we dont use our s3 for such things, so i'll prepare gdrive link if you dont mind
k
Yes that works!
k
Downloading
Done, I will try reproducing locally.
a
you may need to trigger it several times. Sometimes it returns 3k items as it should, but sometimes less than 3k which is not correct. Numbers are always different btw
k
@Anton Khatunzev Do you use HTTPS?
a
at the moment no
k
Okay I will try with http then.
Unable to reproduce. Tried 10 times šŸ¤” Are you running this against a server or on local dev?
a
against the server
i can show you i think
k
Okay let's do that.
k
@Anton Khatunzev I tried uploading multiple times to a server in Frankfurt, which is pretty far from me, but I could not reproduce the line count mismatch. Can I give you a debug build with the
id
also returned in the response? So we can confirm whether only the last few document success status are dropped or documents in the middle of the response are affected.
a
hi, yes, sure. But i dont know when i will be able to test this. Bit busy with another stuff at the moment...
k
Okay, no worries, please ping when you are free sometime this week. In the mean time, I will try launching another server even further away and see if that helps to reproduce.
Also, are you sure that the typesense process did not crash? The truncated http response can also happen if the typesense server had crashed and was subsequently restarted by systemd. Checking the process age will confirm if process had crashed.
a
ok, next time i'll take a look at the process age. Yesterday it looked like it did not crash. But i'm not 100% sure
k
šŸ‘
@Anton Khatunzev I've been able to reproduce this issue. Working on a fix. Will keep you posted.
a
Great! Thank you
k
@Anton Khatunzev Did you get a chance to try with
rcs14
?
a
hi @Kishore Nallan, sorry i forgot to give you feedback. Yes, i installed the rcs14. And it seems to work fine with 500-items batches. No errors. Previously i had problems even with smaller ones. At the moment i cant check it with bigger batches. But probably will be able to do that soon
But i think the problem gone away
k
Thanks for confirming!
a
Hello @Kishore Nallan i just got another weird problem with TS. I have a collection having field named "displaydata_title"(of type string) and when i try to include this field into sort_by statement i get this error: "message":Ā "CouldĀ notĀ findĀ aĀ fieldĀ namedĀ 
displaydata_title
Ā inĀ theĀ schemaĀ forĀ sorting."
k
We don't support sort by string.
a
oh...
k
It's on our roadmap to support.
a
ok, thank you
k
šŸ‘
Can you please give me a sample dataset to reproduce?