5 months ago
The one I have listed here is just one of the sites I have constructed. There is another for a business that I'm working for that also crashed. They both get time out errors. All of my sites are Django. The project connected to this question was created using Railway's Django template. I did that on purpose because SQL isn't one of my strengths. The entire reason I switched to Railway from other services such as Linode and AWS was because of how easy it is to set up a database with you guys. But ever since you started putting these new DB variables, none of the sites I have connected to Postgres won't run. I was getting some connection logs. I don't know why my sites wont work. I haven't touched my code in a few months. Since before the new variables were introduced. I haven't even looked at the sites until recently. But the only site that is still working correctly, is the only Railway project I have that's not connected to your postgres.
This couldn't have come at a worse time. I received two potential job offers and had nothing to showcase so I lost my opportunities. I have a meeting Wednesday for a potential client and I NEED these sites up and running. I can not lose another job offer because of this.
9 Replies
5 months ago
Hello,
You are on the Legacy runtime, please switch to the V2 runtime.
This can be done from within the service settings.
5 months ago
That didn't fix the problem. Why do you guys keep messing with my builds? Last year, one of your employees, Angelo, connected to my repo and deleted files for a template I was building. I'm SO frustrated with you guys. You guys owe me.
5 months ago
Here's a screenshot of his commit. I'm getting really tired of having to fix things YOUR team does.
Attachments
5 months ago
You guys changed most of my environmental variables?!!??!?!
5 months ago
We have not changed any of your variables, please stop making such accusations.
Additionally, that merged PR on a public project has nothing to do with your own project, so I'm not sure the relevance here.
Please provide actually errors so we can help with your missconfigurations.
5 months ago
Well I didn't change anything on my end. The only thing that was changed was on your end. I know that I'm able to connect to the database because I am able to on my local machine with the same environmental variables I've had since I first set up. The only site I have that's still up is the one I haven't connected to a database yet.
I tried using your template system to rebuild it from scratch. The template crashed shortly after launch. I was able to connect to it for a brief moment to see the django verification page. Same issue, it won't connect to the database.
I have another project I haven't touched since before this change. I switched from Legacy to V2 on that and it still doesn't work either. So I would think it's understandable for me to blame your teams' end on this. My sites worked fine without much adjustments for months. Updated a few packages here and there. Made a couple of front end tweaks. Aside from that, I didn't do anything that could be causing this. I didn't mess with the settings.py or any of the backend stuff. I didn't change any of the environmental variables. So please don't tell me to stop making accusations when your service has done nothing to say otherwise. My deduction is very reasonable. If your own templates aren't working, then it has to be your end. Here are the logs for the site I have linked to this discussion. The latest redeploy shows no errors but still shows a connection timeout. I've tried switching to the new environmental variables that you guys added and it's the same error.
File "/opt/venv/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/site-packages/django/db/backends/base/base.py", line 320, in cursor
return self._cursor()
^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/site-packages/django/db/backends/base/base.py", line 296, in _cursor
self.ensure_connection()
File "/opt/venv/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/site-packages/django/db/backends/base/base.py", line 278, in ensure_connection
with self.wrap_database_errors:
File "/opt/venv/lib/python3.11/site-packages/django/db/utils.py", line 91, in exit
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/opt/venv/lib/python3.11/site-packages/django/db/backends/base/base.py", line 279, in ensure_connection
self.connect()
File "/opt/venv/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/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.11/site-packages/django/utils/asyncio.py", line 26, in inner
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 332, in get_new_connection
connection = self.Database.connect(**conn_params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
conn = connect(dsn, connectionfactory=connection_factory, **kwasync)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^
django.db.utils.OperationalError: connection to server at "monorail.proxy.rlwy.net" (35.212.181.170), port 5432 failed: Connection timed out
Is the server running on that host and accepting TCP/IP connections?
5 months ago
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/5d3cdca1-c443-453f-81df-5a1e8ac54395/vol_xoipn7eaqt17e7aj
Starting Container
Certificate will not expire
PostgreSQL Database directory appears to contain a database; Skipping initialization
2024-12-03 15:21:19.996 UTC [5] LOG: starting PostgreSQL 16.3 (Debian 16.3-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-12-03 15:21:19.996 UTC [5] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-12-03 15:21:19.996 UTC [5] LOG: listening on IPv6 address "::", port 5432
2024-12-03 15:21:20.001 UTC [5] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-12-03 15:21:20.009 UTC [28] LOG: database system was interrupted; last known up at 2024-12-03 15:18:25 UTC
2024-12-03 15:21:20.058 UTC [28] LOG: database system was not properly shut down; automatic recovery in progress
2024-12-03 15:21:20.063 UTC [28] LOG: redo starts at 0/1F0F388
2024-12-03 15:21:20.063 UTC [28] LOG: invalid record length at 0/1F0F3C0: expected at least 24, got 0
2024-12-03 15:21:20.063 UTC [28] LOG: redo done at 0/1F0F388 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2024-12-03 15:21:20.066 UTC [26] LOG: checkpoint starting: end-of-recovery immediate wait
2024-12-03 15:21:20.079 UTC [26] LOG: checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.006 s, sync=0.002 s, total=0.015 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=0/1F0F3C0, redo lsn=0/1F0F3C0
2024-12-03 15:21:20.088 UTC [5] LOG: database system is ready to accept connections
2024-12-03 19:59:04.333 UTC [297] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:00:15.628 UTC [299] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:00:35.371 UTC [300] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:02:27.716 UTC [303] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:23:56.512 UTC [326] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:23:58.148 UTC [327] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-03 20:55:55.610 UTC [361] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:20:22.805 UTC [567] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:34:03.172 UTC [582] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:34:04.689 UTC [583] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:34:54.772 UTC [585] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:35:34.630 UTC [586] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:35:35.401 UTC [587] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:45:08.556 UTC [598] FATAL: database "monorail.proxy.rlwy.net" does not exist
2024-12-04 00:46:07.976 UTC [600] FATAL: database "monorail.proxy.rlwy.net" does not exist
5 months ago
Oh my mistake. That last log was caused from me misconfiguring my test environment. I'm able to connect to PG with no issues on my local environment on my laptop.
5 months ago
Oh all of my other logs are saying the same thing. Except for my local machine. All of the environmental variables are the same and it's working on my end. I tried hosing on Digital Ocean with just my code connected to my repo. Digital Ocean works with Django's built in SQLite db, but Railway won't work with SQLite. But the monorail proxy existence errors continue. None of those errors show up when I connect with my development environment which is connected to the same repo as well. This is also the error I am getting on a fresh Django template I just started earlier.