[URGENT] Aplication stop working when adding project in the same workplace
mujirin
PROOP

3 months ago

I have an application, Aksbel.com (built with Django and PostgreSQL), which has been running reliably for more than 6 month at Akselerasi Belajar project and. Last night, I added another application (Schoilas.com) to the same workplace, as a separate project (in Schoilas project) and do nothing in the Aksbel. However, after doing so, Aksbel stopped working and now shows the following error.

I would appreciate your assistance in looking into this issue. Thank you very much.

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/base/base.py", line 256, in connect

self.connection = self.get_new_connection(conn_params)

File "/opt/venv/lib/python3.10/site-packages/django/utils/asyncio.py", line 26, in inner

return func(*args, **kwargs)

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/postgresql/base.py", line 350, in get_new_connection

connection = self.Database.connect(**conn_params)

File "/opt/venv/lib/python3.10/site-packages/psycopg2/__init__.py", line 122, in connect

conn = connect(dsn, connectionfactory=connection_factory, **kwasync)

psycopg2.OperationalError: connection to server at "postgres" (fd12:b3d:a8c:0:9000:31:962a:19d2), port 5432 failed: Connection timed out

Is the server running on that host and accepting TCP/IP connections?

The above exception was the direct cause of the following exception:

raise dj_exc_value.with_traceback(traceback) from exc_value

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/base/base.py", line 279, in ensure_connection

self.connect()

File "/opt/venv/lib/python3.10/site-packages/django/utils/asyncio.py", line 26, in inner

return func(*args, **kwargs)

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/base/base.py", line 256, in connect

self.connection = self.get_new_connection(conn_params)

File "/opt/venv/lib/python3.10/site-packages/django/utils/asyncio.py", line 26, in inner

return func(*args, **kwargs)

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/postgresql/base.py", line 350, in get_new_connection

connection = self.Database.connect(**conn_params)

File "/opt/venv/lib/python3.10/site-packages/psycopg2/__init__.py", line 122, in connect

conn = connect(dsn, connectionfactory=connection_factory, **kwasync)

django.db.utils.OperationalError: connection to server at "postgres" (fd12:b3d:a8c:0:9000:31:962a:19d2), port 5432 failed: Connection timed out

Solved$10 Bounty

Pinned Solution

mujirin
PROOP

3 months ago

Hi everyone, I think I have solved the problem, here the summary:

The error:

App do not respond

502 Bad Gateway

The log:

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Operations to perform:

Apply all migrations: <all table listed here>

What I am done to fix:

# FIXING

## The Error

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

## Backup in the local

### BACKUP

436 export PGHOST="pghost"

437 export PGPORT="pgport"

438 export PGUSER="pguser"

439 export PGPASSWORD="pgpassword"

440 export PGDATABASE="pgdatabase"

441 export PGSSLMODE="require"

442 pg_dump --no-owner --no-privileges --format=plain > backup.sql

after finish

443 ls

you will get

backup.sql

### TEST

444 createdb test_restore\npsql test_restore < backup.sql\npsql test_restore -c "\dt"\n

you will get error here

### ALTER and REINDEX

445 psql -d postgres -c "ALTER DATABASE template1 REFRESH COLLATION VERSION;"\n

446 psql -d postgres -c "ALTER DATABASE postgres REFRESH COLLATION VERSION;"\n

447 psql -d postgres -c "ALTER DATABASE railway REFRESH COLLATION VERSION;"\n

448 psql -d postgres -c "REINDEX DATABASE railway;"\n

449 psql -d railway -c "REINDEX DATABASE railway;"\n

450 psql -d postgres -c "ALTER DATABASE postgres REFRESH COLLATION VERSION;"\n

451 psql -d postgres -c "ALTER DATABASE railway REFRESH COLLATION VERSION;"\n

452 psql -d railway -c "REINDEX DATABASE railway;"\n

453 psql -d railway -c "SELECT current_database();"\n

454 psql -d railway -c "VACUUM (ANALYZE);"\n

455 psql -d railway -c "SELECT pg_database_size(current_database());"\n

Hope this help anyone else.

17 Replies

chandrika
EMPLOYEE

3 months ago

Hi there,

We have an ongoing incident that this related to — we're investigating issues with elevated network latency and slow deploys and working actively to resolve this right now.

Best,

The Railway Team


Status changed to Awaiting User Response Railway 3 months ago


chandrika
EMPLOYEE

3 months ago

Hi there,

We have an ongoing incident that this related to — we're investigating issues with elevated network latency and slow deploys and working actively to resolve this right now.

Best,

The Railway Team


mujirin
PROOP

3 months ago

Hi Chandrika, thank you for responding, please be hurry


Status changed to Awaiting Railway Response Railway 3 months ago


chandrika
EMPLOYEE

3 months ago

Of course! We're move as quickly as possible and have multiple engineers from our platform team working on resolving this right now


Status changed to Awaiting User Response Railway 3 months ago


chandrika

Of course! We're move as quickly as possible and have multiple engineers from our platform team working on resolving this right now

mujirin
PROOP

3 months ago

Cool, good luck Chandrika


Status changed to Awaiting Railway Response Railway 3 months ago


mujirin

Cool, good luck Chandrika

chandrika
EMPLOYEE

3 months ago

Just an update: we are starting to see recovery, so this should be resolving for you soon


Status changed to Awaiting User Response Railway 3 months ago


chandrika

Just an update: we are starting to see recovery, so this should be resolving for you soon

mujirin
PROOP

3 months ago

Both of my application Akselerasi Belajar and Schoilas stil 502 Bad Gateway


Status changed to Awaiting Railway Response Railway 3 months ago


mujirin

Both of my application Akselerasi Belajar and Schoilas stil 502 Bad Gateway

chandrika
EMPLOYEE

3 months ago

Things should be back up now, are you still running into issues? If so, could you please try to redeploy?


Status changed to Awaiting User Response Railway 3 months ago


chandrika

Things should be back up now, are you still running into issues? If so, could you please try to redeploy?

mujirin
PROOP

3 months ago

  1. Aksbel.com (Akselerasi Belajar) still 502 Bad Gatway:

Starting Container

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

No changes detected

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Operations to perform:

Apply all migrations: admin, aksbel_management, auth, barrometrix, braket_class, contenttypes, finance, notification, school, sessions, users

Running migrations:

No migrations to apply.

  1. The Schoilas is working fine


Status changed to Awaiting Railway Response Railway 3 months ago


mujirin
PROOP

3 months ago

[Already redeploy both the django app and the database]

What should I do with the Aksbel.com?

I am newbie here


chandrika

Things should be back up now, are you still running into issues? If so, could you please try to redeploy?

mujirin
PROOP

3 months ago

Already redeploy but still didn't work, help please, my clients depends on it cold_sweat emoji

What should I do with this error:

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.


3 months ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open itsrems 3 months ago


mujirin

Already redeploy but still didn't work, help please, my clients depends on itWhat should I do with this error:WARNING: database "railway" has a collation version mismatchDETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

In a database client (eg, Datagrip), run the following SQL query:

ALTER DATABASE railway REFRESH COLLATION VERSION;


alexxdf28-hue
FREE

3 months ago

1. Application Server Crash / Failure to Bind (Most Likely)

The most common cause is that your application server (Gunicorn, uWSGI, etc.) is failing to start or crashing immediately after the migrations complete, which leaves the main web port unavailable to the proxy.

  • Check Gunicorn/App Server Logs: The absolute most critical step is to find the logs for the Django application server (e.g., Gunicorn's stdout/stderr). This log will contain the actual Python traceback error that is killing your process.

    • Common Causes of Crash:

      • Missing Environment Variables: A required secret key, database URL, or other configuration variable is missing in the development environment.

      • Memory Exhaustion (OOM Kill): If the dev environment has less memory than production, the operating system's Out of Memory (OOM) killer may be terminating your Gunicorn worker processes. Check your platform's resource usage metrics.

      • Incorrect ALLOWED_HOSTS: If the hostname or IP address the proxy is using to reach your container is not in Django's ALLOWED_HOSTS setting, Django will immediately return a "Bad Request (400)" response, which the proxy might misinterpret as a 502 (less common, but possible). Ensure your ALLOWED_HOSTS includes the necessary values for the Railway environment.

  • Action: Look for the full application logs that follow the No migrations to apply message.

2. Port and Host Misconfiguration

The application server may be running, but on the wrong address, meaning the proxy cannot connect to it.

  • Check Bind Address: Ensure your Gunicorn (or other WSGI server) start command is binding to 0.0.0.0 (all interfaces) and the correct port (e.g., 8000 or the port expected by Railway's proxy).

    • Example Gunicorn command:gunicorn myproject.wsgi:application --bind 0.0.0.0:8000

  • Action: Verify the startup command for your service (likely in your entrypoint.sh or the service configuration) is using 0.0.0.0 and the expected port.

3. Railway-Specific Health Check/Timeout

If your app takes a long time to start up (e.g., pre-loading a large ML model or performing a heavy database query), the Railway proxy's default health check or timeout may expire before the application is ready to serve requests, resulting in a 502.

  • Action: If possible, increase the startup/connection timeout in your Railway configuration.

I strongly recommend you find and review the complete logs for your application server (the process running the Django app). The 502 error is a symptom; the real error is in the backend application's logs.


0x5b62656e5d

In a database client (eg, Datagrip), run the following SQL query:ALTER DATABASE railway REFRESH COLLATION VERSION;

mujirin
PROOP

3 months ago

Hi, could you please explain more (where to do this commandALTER DATABASE railway REFRESH COLLATION VERSION;

? Is it in my Django app or ini Railway?

I am newbie here. Thanks a lot


alexxdf28-hue

1. Application Server Crash / Failure to Bind (Most Likely)The most common cause is that your application server (Gunicorn, uWSGI, etc.) is failing to start or crashing immediately after the migrations complete, which leaves the main web port unavailable to the proxy.Check Gunicorn/App Server Logs: The absolute most critical step is to find the logs for the Django application server (e.g., Gunicorn's stdout/stderr). This log will contain the actual Python traceback error that is killing your process.Common Causes of Crash:Missing Environment Variables: A required secret key, database URL, or other configuration variable is missing in the development environment.Memory Exhaustion (OOM Kill): If the dev environment has less memory than production, the operating system's Out of Memory (OOM) killer may be terminating your Gunicorn worker processes. Check your platform's resource usage metrics.Incorrect ALLOWED_HOSTS: If the hostname or IP address the proxy is using to reach your container is not in Django's ALLOWED_HOSTS setting, Django will immediately return a "Bad Request (400)" response, which the proxy might misinterpret as a 502 (less common, but possible). Ensure your ALLOWED_HOSTS includes the necessary values for the Railway environment.Action: Look for the full application logs that follow the No migrations to apply message.2. Port and Host MisconfigurationThe application server may be running, but on the wrong address, meaning the proxy cannot connect to it.Check Bind Address: Ensure your Gunicorn (or other WSGI server) start command is binding to 0.0.0.0 (all interfaces) and the correct port (e.g., 8000 or the port expected by Railway's proxy).Example Gunicorn command:gunicorn myproject.wsgi:application --bind 0.0.0.0:8000Action: Verify the startup command for your service (likely in your entrypoint.sh or the service configuration) is using 0.0.0.0 and the expected port.3. Railway-Specific Health Check/TimeoutIf your app takes a long time to start up (e.g., pre-loading a large ML model or performing a heavy database query), the Railway proxy's default health check or timeout may expire before the application is ready to serve requests, resulting in a 502.Action: If possible, increase the startup/connection timeout in your Railway configuration.I strongly recommend you find and review the complete logs for your application server (the process running the Django app). The 502 error is a symptom; the real error is in the backend application's logs.

mujirin
PROOP

3 months ago

Hi, thanks for your response, really appreciate. I am not quite understand your point, it is still crash, here the logs

2025-12-16 19:39:34.575 UTC [49] WARNING: database "railway" has a collation version mismatch

2025-12-16 19:39:34.575 UTC [49] DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

2025-12-16 19:39:34.575 UTC [49] HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

The errors that follows the

No migration to apply

is the following

No changes detected

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Operations to perform:

Apply all migrations: admin, aksbel_management, auth, barrometrix, braket_class, contenttypes, finance, notification, school, sessions, users

Running migrations:

No migrations to apply.


chandrika

Things should be back up now, are you still running into issues? If so, could you please try to redeploy?

mujirin
PROOP

3 months ago

Hi, I think the key to resolved the issue is in this log

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Operations to perform:

Apply all migrations: admin, aksbel_management, auth, barrometrix, braket_class, contenttypes, finance, notification, school, sessions, users

could you please guide me how to do this?

thank you


mujirin
PROOP

3 months ago

Hi everyone, I think I have solved the problem, here the summary:

The error:

App do not respond

502 Bad Gateway

The log:

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Operations to perform:

Apply all migrations: <all table listed here>

What I am done to fix:

# FIXING

## The Error

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

## Backup in the local

### BACKUP

436 export PGHOST="pghost"

437 export PGPORT="pgport"

438 export PGUSER="pguser"

439 export PGPASSWORD="pgpassword"

440 export PGDATABASE="pgdatabase"

441 export PGSSLMODE="require"

442 pg_dump --no-owner --no-privileges --format=plain > backup.sql

after finish

443 ls

you will get

backup.sql

### TEST

444 createdb test_restore\npsql test_restore < backup.sql\npsql test_restore -c "\dt"\n

you will get error here

### ALTER and REINDEX

445 psql -d postgres -c "ALTER DATABASE template1 REFRESH COLLATION VERSION;"\n

446 psql -d postgres -c "ALTER DATABASE postgres REFRESH COLLATION VERSION;"\n

447 psql -d postgres -c "ALTER DATABASE railway REFRESH COLLATION VERSION;"\n

448 psql -d postgres -c "REINDEX DATABASE railway;"\n

449 psql -d railway -c "REINDEX DATABASE railway;"\n

450 psql -d postgres -c "ALTER DATABASE postgres REFRESH COLLATION VERSION;"\n

451 psql -d postgres -c "ALTER DATABASE railway REFRESH COLLATION VERSION;"\n

452 psql -d railway -c "REINDEX DATABASE railway;"\n

453 psql -d railway -c "SELECT current_database();"\n

454 psql -d railway -c "VACUUM (ANALYZE);"\n

455 psql -d railway -c "SELECT pg_database_size(current_database());"\n

Hope this help anyone else.


Status changed to Solved chandrika 3 months ago


Loading...