Signup/Login missing in deployed Wasp app
I'm using the OpenSaaS template to translate my research Python scripts into a SaaS webapp. I am using Wasp v0.15.0 and am developing on macOS with Apple Silicon.
Everything works locally, including email signup, login/logout and access control to certain areas of the webapp based on subscriptions status or plan. However, when I deploy to fly.io following the Wasp Deployment guide, one part of the webapp does not work: in my local version, there is a login button in the top right corner of my landing page that, once logged in, turns into a dropdown menu that displays the user email address as seen in the first picture. This part is completely missing in my deployed app as seen in the second picture.
During deployment, the terminal output did not hint at any big issues except for this (for the server application), even though I do not think that this causes the described behavior:
I checked the browser console after cold-starting the client webapp and it said that it failed to load the auth part with error 502. However, when I reloaded the client webapp, this error went away. I figure that this only happened since the server side of my webapp was probably cold-started the first time it failed to load the auth component, and when I reloaded the client webapp, the auth part could actually be fetched (the errors went away) but the actual auth logic and the dropdown menu is still missing.
Do you have any idea why this whole part of the webapp is missing on fly.io? Thanks in advance! 🤝🏻
28 Replies
Hi @Dom. 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 in the knowledge sources, I can offer some insights and potential solutions to your issue with the missing signup/login functionality in your deployed Wasp app on fly.io. This problem seems similar to issues other users have encountered.
1. Check server logs and network requests:
First, it's important to investigate what's happening on the server side. As suggested by Community Member 2 in a similar case, you should check the server logs on Fly.io (https://discord.com/channels/686873244791210014/1217941277979574315) and examine the network requests in your browser's developer tools. This can help identify if the server is receiving requests from the client and if there are any errors being reported.
2. Environment variables:
Make sure you've set up all the necessary environment variables for your deployed app. As Community Member 1 mentioned in a support thread (https://discord.com/channels/686873244791210014/1217758453326680095), you might need to set the
REACT_APP_API_URL to your server URL. Double-check that all required environment variables are correctly set for your production environment.
3. CORS issues:
The problem could be related to CORS (Cross-Origin Resource Sharing) settings. In a similar case (https://discord.com/channels/686873244791210014/1217941277979574315), Community Member 2 suggested that the server might be rejecting requests due to CORS errors. Ensure that your server is configured to accept requests from the correct client URL.
4. Database migrations:
If you've made any changes to your database schema, make sure you've run the necessary migrations on your production database. As Community Member 152 reported (https://discord.com/channels/686873244791210014/1217295340785635418), running a database migration and redeploying solved their login/signup issues.
5. Wasp version:
Although you're using a newer version (0.15.0), it's worth noting that some users have resolved similar issues by updating to the latest Wasp version. Community Member 8 suggested (https://discord.com/channels/686873244791210014/1201898985300971540) updating Wasp as a potential solution in a similar case.
6. Cold start issues:
The 502 error you're seeing on the initial load could indeed be related to a cold start of your server. This is a common issue with serverless deployments. You might want to consider implementing a warm-up strategy or using a paid plan on Fly.io that keeps your instances warm.
7. Custom domain setup:
If you're using a custom domain, ensure it's properly set up. Community Member 1 pointed out (https://discord.com/channels/686873244791210014/1201898985300971540) the importance of setting up CNAME records correctly for custom domains on Fly.io.
To further debug this issue:
1. Double-check all your environment variables and CORS settings.
2. Examine the server logs on Fly.io for any errors related to authentication or API requests.
3. Use the browser's developer tools to check for any failed network requests or JavaScript errors.
4. Try redeploying your app after ensuring all configurations are correct.
If the problem persists after trying these steps, you might want to share more detailed logs or error messages from both the client and server side to get more specific help from the Wasp community.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Dom, 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?Thank you @kapa.ai , I checked the forum posts you mentioned but didn't find an answer. I did check the fly.io logs for my client and server app and found that I keep getting a recurring error about the STRIPE_API_KEY being undefined. This error happens every time the server app is started, so I figure this causes this issue. I do have a Stripe API key in my .env.server file, and locally the Stripe checkout also works already. Do I have to specifically indicate the Stripe API environment variable when deploying? I understood that Wasp takes care of that for me
To me this doesn't seem like a Stripe issue,
is your web client url and server url including envs properly configured and given to fly CLI?
This looks like an app-level error.
@Dom Thanks for the great explanation of the error. I assume you are using OpenSaas. @Vinny (@Wasp) Please see if this issue looks familiar to you (check the screenshots).
Yes you need to add the env variables to your deployed app. Make sure you follow the instructions here carefully, including going to the Wasp Deployment docs to see how to set your env variables https://docs.opensaas.sh/guides/deploying/
OpenSaaS.sh
Deploying
Open SaaS is a free, open-source, full-stack SaaS starter kit for React + NodeJS.
Deploying with the Wasp CLI | Wasp
Wasp CLI can deploy your full-stack application with only a single command.
@Killshot @Filip @Vinny (@Wasp) thanks to all of you for pitching in. After correctly configuring my environment variables the error regarding the Stripe API key went away. I have checked the logs on fly.io and can narrow it down to a communication error between the server and client app. While the myapp-client logs look good...
... the myapp-server logs are littered with messages:
Wohooo @Dom, you just became a Waspeteer level 1!
What stands out to me is that the myapp-server log has a line stating
This would obviously explain why the instance refused connection since it needs my app to listen to
However, my fly-server.toml file (created during first deployment, I did not make any changes to it since) specifies the internal port to 3000:
I searched my whole project for any code that specifies this port 8080 but did not find anything. Do you have an idea why myapp-server is listening to the wrong port even though it is specified in the fly-server.toml file?
I've also browsed the fly.io forum and found one post talking about the and potentially causing this. While I have not changed my fly-server.toml file to configure the myapp-server app to never shut down, I once manually forced the myapp-server app to start before navigating to the URL of myapp-client, but to no avail. This caused the same instance refused connection message in the logs.
https://discord.com/channels/686873244791210014/1308740789316354108/1309439561297821786
Did some more digging and found the solution: the environment variable for PORT was incorrectly set to 8080, so I manually changed it on fly.io under Secrets > PORT to 3000 and re-deployed with my client environment variables and now everything works as intended! 🚀
Just one final question before I mark this question as solved: when is the PORT variable set to 8080 and why?
yes i was just gonna say this....
PORT has to be defined as well to 3000
oh weird. I can't answer this for you... maybe someone else can.
But I'm glad you found the solution. Nice detective work you did there 🙂
Me :D #Prisma Studio Deployed App (Fly)
Check latest message with the solution
Yes, it sounds like you had the same problem @NEROX . Did you ever figure out why your PORT was set to 8080 before manually changing it?
Wohooo @Dom, you just became a Waspeteer level 2!
Hm yeah, if we had multiple peple with PORT set to 8080, we should look into it for sure. So that port should be set by
wasp deploy fly deploy, to 3000, if I am correct. Is it possible that is not happening?I initially deployed my app without specifying any environment variables, and the PORT environment variable was still defined under Secrets on fly.io. Since you @NEROX also deployed without any environment variables first, I figure that this is some kind of default value that is set if not specified otherwise.
@Dom but did you deploy with
wasp deploy fly deploy? if so, PORT was supposed to be set up for you.Yes, I did exactly that, including my client environment variables
Just forgot to also specify my server enironment variables when I ran this for the first time and added them later when I re-deployed two, three times in the hopes of fixing the port issue
Ok got it @Dom . That hsouldn't have caused issues though, but I do wonder if those redeployes somehow messed up the PORT variable. Hm weird. I will open an issue for this for us to investigate, thanks for the details.
Ok, here it is: https://github.com/wasp-lang/wasp/issues/2398
GitHub
When deploying on fly, server PORT is set to 8080 instead of 3000? ...
We had two users encounter this situation. It is not clear how that happened -> they used wasp deploy fly deploy and that should have set PORT to 3000, not 8080. We should investigate to figure ...
From my point of view what makes the port change is that the server explodes more than 10 or 20 times, restarts and then changes the default port.
Wait. in our Wasp manual deployment guides it says this regarding the env vars:
Ok I just encountered the same issue and I think its becasue the DB failed to launch when running the first deploy command so I had to create a db and set the port to 3000 manually
weird
I left a comment on the issue above!
wow 10 or 20 times how does that happen?'
in my case deploy an app without required vars, I go to make a coffee and then when I enter the server logs I see that it has “tried” to restart and compile all those times but as always it is missing some Var. I could recreate the situation by incompletely deploying an app.
Ok I got it, so missing env vars
@miho is currently working on a nice solution for that btw, so soon Waps might be much more helpful about that
Yeah, that's something we want to avoid! Ideally, the server would tell you "Hey, these 3 env vars are missing, go add them" and die 😄