Forums

I'm experiencing a persistent issue with my "always on tasks" on PythonAnywhere, specifically related to DNS resolution failures when running Django-Q.

Here are the details:Environment: Django version: 3.x Django-Q version: 2.x Python version: 3.10 Database: PostgreSQL

Error Log:May 30 01:49:58 --- Logging error --- May 30 01:49:58 Traceback (most recent call last): May 30 01:49:58 File "/home/xxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/django/db/backends/base/base.py", line 282, in ensure_connection May 30 01:49:58 self.connect() May 30 01:49:58 File "/home/xxxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/django/utils/asyncio.py", line 26, in inner May 30 01:49:58 return func(args, kwargs) May 30 01:49:58 File "/home/xxxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/django/db/backends/base/base.py", line 263, in connect May 30 01:49:58 self.connection = self.get_new_connection(conn_params) May 30 01:49:58 File "/home/xxxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/django/utils/asyncio.py", line 26, in inner May 30 01:49:58 return func(args, kwargs) May 30 01:49:58 File "/home/xxxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/django/db/backends/postgresql/base.py", line 215, in get_new_connection May 30 01:49:58 connection = Database.connect(conn_params) May 30 01:49:58 File "/home/xxxxxx/.virtualenvs/digital_dream_partner_venv_pt_br/lib/python3.10/site-packages/psycopg2/init.py", line 122, in connect May 30 01:49:58 conn = _connect(dsn, connection_factory=connection_factory, **kwasync) May 30 01:49:58 psycopg2.OperationalError: could not translate host name "xxxxxxx" to address: Temporary failure in name resolution

...

May 30 01:49:58 django.db.utils.OperationalError: could not translate host name "ASLDev270-3076.postgres.pythonanywhere-services.com" to address: Temporary failure in name resolution

Does it ever connect successfully? If so, you could implement a retry mechanism.

It does. Simetimes it is fast, but simetimes it takes a lot of time. What do you mean by a retry mechanism?

I mean to let your code retry the connection X times before an error is raised.

Yes, this is already implemented. It’s a queue system with retries for failures. The problem is that sometimes it takes too long to re-establish the connection, significantly impacting user experience. Shouldn't this be a correction on the "always on tasks" side?

Thank you for your assistance.

We will need to take a look, but DNS problems like that are hard.

As a workaround, I am currently running the task directly in the console. I would like to know the likelihood of the console being reset and if there is any mechanism for automatic task reset or notification.

Consoles are reset to manage the service depending on load.