Updating and redeploying Postgres DB in Railway
Do I have to manually update/redeploy the Postgres database in Railway? I've reployed the app but the new Prisma schema is not reflected in the database.
On top of this, I'm also having this problem after redeployment again:
Access to XMLHttpRequest at 'https://server-production-....railway.app/auth/me' from origin 'https://...' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Maybe, it's somehow connected?
13 Replies
Hi @mb23. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information provided, it seems like you're facing two separate issues: one related to the Prisma schema not being reflected in the database after redeployment, and the other related to a CORS policy error.
For the first issue, the Wasp documentation does not provide specific instructions on updating the Postgres database on Railway after redeployment. However, it does mention that you need to run
wasp build to rebuild your app whenever you make updates and need to redeploy source (https://wasp-lang.dev/docs/advanced/deployment/manually#updates--redeploying). If you've made changes to your Prisma schema, make sure you've run this command before redeploying. If the issue persists, it might be related to how Prisma handles migrations and you might need to run specific Prisma commands to apply the changes to your database.
As for the second issue, the CORS policy error is likely due to your server not being properly configured to accept requests from the origin you're making the request from. This is not directly related to Wasp or Railway, but rather to how your server handles CORS (Cross-Origin Resource Sharing). You'll need to configure your server to include the 'Access-Control-Allow-Origin' header in its responses, and this header should include the origin you're making the request from. This is a common issue in web development and is not specific to Wasp or Railway.
Unfortunately, without more specific information or code examples, it's difficult to provide a more detailed solution. I would recommend checking the documentation for Wasp, Prisma, and Railway, and possibly reaching out to their respective communities for more help.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @mb23, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Hey @mb23!
I don't think the two problems are connected. Let's first deal with the CORS issues.
This error ("Access to XML...") happens when your client and your server are deployed on different origins (port, domain, or protocol) and you haven't told your server where the client is.
You do this by specifying the
WASP_WEB_CLIENT_URL env var. So, my questions are:
- What's your frontend URL?
- What's your backend URL?
- Did you set WASP_WEB_CLIENT_URL to the frontend URL on the backend server?
- Are you using Custom APIs or only Operations (queries and actions)?@sodic Thanks a bunch for your response, really appreciate it!
What's your frontend URL?
https://client-production-1a2d.up.railway.app/, redirected to custom domain: https://contentforce.ai
What's your backend URL?
https://server-production-549d.up.railway.app
Did you set WASP_WEB_CLIENT_URL to the frontend URL on the backend server?
Yes, WASP_WEB_CLIENT_URL=https://contentforce.ai
Are you using Custom APIs or only Operations (queries and actions)?
I'm only using the stripeWebhook API of the OpenSaaS template. But besides that, I've added additional Wasp jobs.
Here's my variables set up for client and server:
client:
PORT=8043
REACT_APP_API_URL=https://server-production-549d.up.railway.app
REACT_APP_STRIPE_CUSTOMER_PORTAL=...
server:
ADMIN_EMAILS=...
DATABASE_URL=${{Postgres.DATABASE_URL}}
HOBBY_SUBSCRIPTION_PRICE_ID=
JWT_SECRET=...
PORT=8043
PRO_SUBSCRIPTION_PRICE_ID=...
SECRET_KEY=...
SENDGRID_API_KEY=...
STRIPE_KEY=...
STRIPE_WEBHOOK_SECRET=...
WASP_SERVER_URL=https://server-production-549d.up.railway.app
WASP_WEB_CLIENT_URL=https://contentforce.ai
Hey @mb23, welcome back and thanks for the detailed response!
Looks like it's not an application error after all. The real error is not the "Access to XMLHttp...", it's actually that your server doesn't seem to be up:
Railway returns a default "server is down" response, which your frontend then tries to process and errors out, thinking it's an "Access to Xml..." problem
When I access your server from the browser, I get this:
Do you know why the server is down? Perhaps it crashed because the database is out of sync (so it might be related after all)?
@sodic good question. The server crashed 10 mins ago. I'm just trying to redeploy it but it's not working. Sorry, I'll have to get back to you as soon as it's up again. I think it wasn't the issue before. 🙂
@sodic Sorry for the delay. I really tried a lot to reploy server and client. Finally, it worked. Now, I don't have a Cors error but get this one:
That one is not an eror I believe. It's just the server telling the client they aren't logged in (we should change that status code though, many find it confusing).
Can you log in and use the app normally?
@sodic Yes, you're completely right haha! it worked 🙂 Thanks for your help 🙂
happy to help, but we still need to take care of migrating your production database 😄
Or did you figure that one out?
Server, when deployed, automatically tries to migrate the prisma schema to the latest version -> so I am guessing once server was successfuly deployed, that also happened and is now ok.