Hi team! It looks like typesense have queue for sc...
# community-help
d
Hi team! It looks like typesense have queue for schema altering, can I somehow flush it? I had bad configurator run and now I have
Processing field additions and deletions first...
every few minutes
k
Every few minutes? Does Typesense server keep getting restarted?
d
Right now not, but I have unlucky restarts + applying same drop + add field over and over again
Running GC for aborted requests, req map size: 38
k
There are no loops in the alter schema code, so if that keeps appearing then it probably means that the server is starting over and replaying recent writes from the write ahead log.
d
So I need just wait until all requests are done
k
Running GC for aborted requests, req map size: 38
This is different, not related.
How are you applying the schema update? What client do yo uuse?
I think what could be happening is that the operation takes a long time, but your client has a short default timeout and it gets retried over and over again.
d
I’m using python client + self-written wrapper, which converts config file with schema declaration into actions which should make typesense state the same as. config. I had error in this code, so it had ran dropping + adding the same exact field over and over again. I’m just looking maybe I can speedup this process
k
over and over again
AFAIK this should not happen at all because there is no inherent looping in the update schema code. So either of the two are happening: a) Server is restarting after a crash and replaying recent writes from the write ahead log b) The client is getting timed out and the official Typesense client retries the API call if there is a timeout
I will rule out b) first. Ensure that the client has a large timeout value configured so that the write call is not retried on timeout error.
The other thing that could have happened is that the client treats the bad schema request as a server error and retries 🤔
d
This is different, not related.
Are you sure? It decreases every time after succesful processing:
Copy code
Alter payload validation is successful...                                                                                                                                                              Processing field additions and deletions first...     
Running GC for aborted requests, req map size: 34                                                                                                                                                  Finished altering 105713 document(s).                                                                                                                                                                  Processing field modifications now...                                                                                                                                                                  
Finished altering 105713 document(s).


Alter payload validation is successful...                                                                                                                                                              
Processing field additions and deletions first...                                                                                                                                                      
Running GC for aborted requests, req map size: 33
Finished altering 105713 document(s).                                                                                                                                                                  
Processing field modifications now...
Finished altering 105713 document(s).
k
What that shows is that a bunch of requests have been queued up and they are being processed one by one. This happens for all writes. So indeed the client seems to have sent a schema alter request repeatedly.
👍 1
One way to stop this is to restart the server with the
--skip-writes
flag.
This will skip ALL queued writes. Then you can trigger a manual snapshot call (check operations end-point) and then those logs will be purged and then you are restart server again without that flag.
d
a) Server is restarting after a crash and replaying recent writes from the write ahead log
This is exactly what happened
k
But the logs above don't suggest a restart. The requests are queued by and replayed.
Unless you see a stack trace along with the crash?
d
Maybe because it was multiple time before and after restart? 🤔 My idea what was happened: • I have statefulset with 1 node of typesense + post-update configurator job • I ran heavy schema altering by error (delete two rows, index them again) • It caused deploy timeout, so deploy was reverted (typesense restarted, post-update configurator job ran again) • I retry this process a few times until found what’s going on
k
Yes that's possible
d
And yes, I got timeout in my client:
HTTPConnectionPool(host=‘typesense’, port=1234): Read timed out. (read timeout=20)
Do I need to set up bigger timeout for altering field schema migration?
k
Yes, definitely. Default value of a few seconds will be too small for larger collections. Or just use
curl
which does not timeout by default.
d
Yep, you also was right about python client. It looks like it retries requests even for patch/post requests
k
Which is fine for most cases, but maybe a gotcha for long running requests.
👍 1
d
I will tweak timeout and max_retries
👍 1