Random cursor already closed error when downloading translations via REST API #1108
Labels
question
This is more a question for the support than an issue.
Comments
|
This seems to be specific to some Docker environments - it seems that the connection between Weblate and PostgreSQL is closed prematurely. It has been reported several times, but none of them really lead to resolution, for example see #786.
Weblate has to figure out whether user has permissions to access the file and find out it's filename, this all is stored in the database... |
Of course, makes sense. That was a stupid question.
Any further information we can provide?
The linked SO post (https://stackoverflow.com/questions/31504591/interfaceerror-connection-already-closed-using-django-celery-scrapy) was the one we were referring to. What are your thoughts on the proposed solution? Could it work in Weblate? We use currently a retry logic on our build server to work around the problem. So far it works. But the error reports from Weblate start to get a bit annoying. We receive almost every day a few. |
|
This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger. In case your question is already answered, making a donation is the right way to say thank you! |
|
The SO post discusses connection issues from the Celery worker what is not something we see here (and I also believe this has been addressed upstream already). Celery plays no role in the download request. celery/django-celery#121 (comment) suggests to configure SSL mode for the connections, can you try whether it makes a difference? Setting POSTGRES_SSL_MODE: require in the Docker environment should do that. |
Took a bit to figure out how to enable SSL in the PostgreSQL docker container, but https://gist.github.com/mrw34/c97bb03ea1054afb551886ffc8b63c3b was helpful. Since we activated SSL yesterday afternoon there haven't been any more errors. Because of the random nature of the issue, we will monitor it a few days to be sure that it is really fixed. We will post an update next week. Thanks for your help so far. |
|
Maybe |
|
In WeblateOrg/weblate#3942 the used database was postgres:9.6-alpine. We use currently the same version. Maybe a database update will help. We will try migrating our database to the latest version during this week. |
|
Upgraded yesterday to postgres:13-alpine, but the errors remain. Do you have other ideas what we could check or try @nijel? Not sure if it is related to this problem, but we noticed a different error tonight amoung the others: |
|
I can see the following reasons why the connection would be closed:
|
|
This issue has been automatically marked as stale because there wasn’t any recent activity. It will be closed soon if no further action occurs. Thank you for your contributions! |
|
We activated the connection logging and here is the output from the Weblate and database container. Unfortunately, we weren't able to get a merged log from docker. There are multiple disconnects in the log, but one looks a bit suspicious because the session time is very short and it was just before the error in weblate: Do you see anything else of interest? We are aware that it is not the real solution and just works around the probelm, but have you thought about a bit of retry-logic? |
|
Retrying is not really an option - it's deep in the Django code. https://stackoverflow.com/q/65969151/225718 seems similar, but no answer is there.... |
|
This issue has been automatically marked as stale because there wasn’t any recent activity. It will be closed soon if no further action occurs. Thank you for your contributions! |
|
Reopening as we're still occasionally seeing this kind of errors. Important question to anybody hitting this: Do you get the error on client, or you can only see it in the log? The reason I ask is that it seems that it could be visible only in the logs - client closes connection to the nginx, it tells uwsgi to stop the request, it calls There is a change to switch to gunicorn what avoids these errors at least in one case: main...porscheinformatik:gunicorn The reason is that it uses proxy protocol instead of uwsgi and in this case, gunicorn always completes the request, so the error does not happen. PS: gunicorn actually never terminates running request, see benoitc/gunicorn#2577 |
We also see the error on the client (HTTP 500). When putting the server under load the users will occasionally get the error page. If you want to use the gunicorn version we provide the package here https://github.com/porscheinformatik/weblate-docker/pkgs/container/weblate (tag 4.9-1-gunicorn for the current version). |
5 tasks
|
The issue you have reported is now resolved. If you don’t feel it’s right, please follow its labels to get a clue for further steps.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When downloading translation using the REST API (/api/translations////file/) it sometimes fails, and the server reports an error (type: interface error, value: cursor already closed).
I already tried
To Reproduce the issue
Steps to reproduce the behavior:
Expected behavior
Files should download without a problem.
Exception traceback
Server configuration and status
Weblate installation: Docker
Weblate deploy checks
Additional context
What we don't quite understand is why the database is accessed at all in this situation. Isn't the file just download from the repository as it is?
The text was updated successfully, but these errors were encountered: