I am using the REST API a lot in my script to control Syncthing. In order to have a robust script I often check if the Syncthing daemon responds to Ping API calls, before I do other calls like GET or POST /rest/system/config.
If a machine does not respond to the ping I mark it unreachable and try to restart the daemon or wait until later.
Unfortunately I have noticed that sometimes the response to the ping request does work, while the response of the Config requests ran into a timeout.
I noticed the issue a few times while doing manual HTTP requests, and it appeared after reproducible in the manner that all ping requests worked and certain other requests timed out. (status, GET and POST config)
Do you have any experience with this? While I was able to reproduce the symptoms after they appeared I do not have a procedure to reproduce it. I cannot rule out that it is a machine issue on my side.
It hurts me a lot since the “unreachable” status is set and unset by ping requests in my script. I do not know if I should change it to another request call.
It could be due to slow io and us holding locks for a long time. Is the timeout client side or server side (not sure if we even have anything server side). If its client side, increase it.
Also, I suggest you check resource usage and logs around the time this happens.
It most definitely has something to do with the respective machine being slow or having a bad network.
I will look into it and maybe try to increase the timeout when I see it arising again. I could not see anything suspicious in the logs, but as far as I have seen there are no entries about HTTP requests in the logs except for ConfigSaved maybe.
You can enable http logging to see how long requesrs take, also, you could run blocking profiler to see where most blocking time is spent, it might be explained in -help how to do that.