n8n redis connection timing out after update

I have tried rolling back all 4 n8n containers to 2 weeks ago and I'm still seeing redis connection timeouts and the UI error "Cannot GET /projects/wfVfXkYfvphTp1eX/workflows"

This is very frustrating. Can anyone help?

This isn't recommended but is n8n able to connect to Redis (and/or Postgres if applicable) through the public URL?

I tried changing it and it still timed out.
Another thing to note is the Railway UI won't load the data from the Redis server either.
Would this indicate an infrastructure issue on the Railway side?
And I have Redeployed this as well.

Are you able to connect to Redis through a database client (eg, Datagrip)?

I haven't tried. But my guess would be no since nothing else in the same environment will connect to it.

Downloading it now to give it a try. Not confident.

That's a roger o Datagrid. It gets a successful ping to the public URL.

I have been able to connect through it also.

Are you able to write keys and values to it?

(I'd assume yes)

I've not used DataGrid before so I'm not sure how to test for that.

That's fine. This might be something related to Railway as you're able to connect from your local machine, I'm not too sure. This is out of my area of knowledge unfortunately. Sorry couldn't be of much help.

Thanks for trying @pepper . Yes, it's a bit out of my comfort zone as well.

UPDATE: This is obviously a Railway issue. Where are all the support folks from Railway here?
I have removed most of the QUEUEBULL related vars. I have kept QUEUEBULLREDISURL, QUEUEBULLREDISPASSWORD, and QUEUEBULLREDISTIMEOUT_THRESHOLD.
This is because I could connect from my PC and see the Redis data in DataGrid using the Public URL. The Private data connection failed in DataGrid.

So if I can connect to the data remotely, why can't Railway connect container to container?

Log files for Primary container showing the recurring crashes.

1443097403367620630

Note that using the private network URL will not work outside of your project. It’s only available within your Railway project.

Understood. But it also wasn't working within my Railway project either.

I believe I have this resolved.
I reset all of the specific QUEUE_BULL vars to the Public URL credentials and kept the QUEUE_BULL_REDIS_URL value set to the public URL.
I did this on both the Primary and Worker containers and … drum roll please … everything came up beautifully in n8n with active Workflows operational again.

I realize using the Public URL is not recommended. But this is the only way I have been able to get his working.

I would welcome some input from Railway on this and any help on getting the environment working on the latest version of n8n with the proper Redis configuration.

(Another lil reminder that you will be charged egress fees when using public URL.)

This is bullshit! It is NOT a misconfiguration. All I did was update n8n and it trashed YOUR configuration.
This was installed from your original n8n package.
I would like everyone to know this. I installed your package, and then did an update, now you want to blame me for a mis-configuration.

Big middle finger to you guys. Railway has just scored a major black mark in my book

IT IS A PLATFORM ISSUE!

Lazy dickheads!

Adjust your platform to handle potential upgrades.

@pepper So now I will get charged extra because their private network no longer works? Fucking idiots!

@Brody You didn't even offer any helpful advice. If it is not a platofrm issue, why don;t you offer some suggestions about how this is misconfigured? How could this have gone from working to broken just from an update. I would really like some possible solutions to fix this problem.
I don't know how your team has set this up or why the networks connections within my container have suddenly stopped working.
Please pull your finger out of your ass and help me understand how I can fix the problem.
Thank you.