This is a technical issue, made evident by a faulty AbortController override. In my case, the abort method in the AbortController did not work.
What did you expect to happen?
Be able to use external engines with the Lichess Local Engine application.
What happened instead?
Was getting a lot of 503 errors after 15 seconds and the engine was not usable. LLE was stuck on the same position.
Operating system
Windows 11
Browser and version (or alternate access method)
Brave
Additional information
From my investigation, the /analyse API was probably waiting for the previous call to end, but as the fetch was never aborted, the new call would always timeout. I think that if there is a way to determine a second call was made, then the first one should be aborted by the server without expecting an abort from the client.
Also, 503 is quite an unhelpful HTTP code. 444 or 499 would be much more clear, or perhaps add some information in the response content like "timeout" "waiting for previous call to end" etc.
I've had to resort to daily restarts of my external-engine service to work around some unknown issue which causes analysis to get stuck. It wouldn't surprise me if my issue is the same as this issue.
Exact URL of where the bug happened
https://engine.lichess.ovh/api/external-engine/.../analyse
Steps to reproduce the bug
This is a technical issue, made evident by a faulty AbortController override. In my case, the abort method in the AbortController did not work.
What did you expect to happen?
Be able to use external engines with the Lichess Local Engine application.
What happened instead?
Was getting a lot of 503 errors after 15 seconds and the engine was not usable. LLE was stuck on the same position.
Operating system
Windows 11
Browser and version (or alternate access method)
Brave
Additional information
From my investigation, the /analyse API was probably waiting for the previous call to end, but as the fetch was never aborted, the new call would always timeout. I think that if there is a way to determine a second call was made, then the first one should be aborted by the server without expecting an abort from the client.
Also, 503 is quite an unhelpful HTTP code. 444 or 499 would be much more clear, or perhaps add some information in the response content like "timeout" "waiting for previous call to end" etc.