How do I debug why an actions endpoint is returning a 404?
Here's what I am seeing in the logs for the server
2024-06-18T10:00:10Z app[redacted] sin [info]GET /auth/me 304 5.758 ms - -
2024-06-18T10:00:10Z app[redacted] sin [info]POST /operations/update-current-user 404 0.332 ms - 170
However, this was working when tested locally. The auth seems to be working fine, so I don't think it is a DB connection issue.
I am also seeing this after a deploy:
redacted
2024-06-18T16:42:41Z app[redacted] sin [info]🔍 Validating environment variables...
2024-06-18T16:42:42Z app[redacted] sin [info]🚀 "Email and password" auth initialized
2024-06-18T16:42:42Z app[redacted] sin [info]Server listening on port 8080
I am using the same update user action as defined in the OpenSaaS template.
9 Replies
Hi @KC (GitHub @Case-E). 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 the
update-current-user action is not being recognized by the server, hence the 404 error. Here are a few steps you can take to debug this issue:
1. Check your actions.ts file: Ensure that the update-current-user action is correctly defined and exported in your actions.ts file. If you're using the OpenSaaS template, you should have something similar to the createTask and updateTask actions defined in the Wasp tutorial (https://wasp-lang.dev/docs/tutorial/auth#updating-operations-to-check-authentication).
2. Check your main.wasp file: Make sure that the update-current-user action is correctly imported in your main.wasp file. If the action is not imported correctly, it won't be recognized by the server.
3. Check for typos: Ensure that the action name is spelled correctly in both the actions.ts file and wherever it's being called in your application. A simple typo could cause a 404 error.
4. Check the server logs: Look for any error messages in the server logs that might indicate what's going wrong. If there's an issue with the action itself (for example, if it's throwing an error), it should show up in the logs.
5. Test locally: Since you mentioned that it was working locally, try to identify any differences between your local environment and the production environment. This could include differences in the database, environment variables, or even the version of Wasp being used.
If none of these steps help, you might want to consider reaching out to the Wasp community on Discord (https://discord.com/channels/686873244791210014/1216119302244270181) or opening an issue on the Wasp GitHub page (https://github.com/wasp-lang/wasp/issues). They might be able to provide more specific assistance based on your exact setup and issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @KC (GitHub @Case-E), 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?It seems to have gotten fixed in the next deploy. No longer seeing that error, I would still love to know what the best way to debug issues like this would be. 😄
Wohooo @KC (GitHub @Case-E), you just became a Waspeteer level 3!
That is very weird! So it seems like your server was successfuly deployed, but then it reported 404 on somebody trying to access that operation. Which means it was working, but it returned 404.
What might have happened is that you tried to update a user which doesn't exist? So it returned 404 due to failed prisma command?
I don't see how redeployment might have helped, this part of the ssytem is quite stable and flakiness like this has no theoretical reason. Let us know if sometihn glike this happens again, and any details you might have around it help! Does it happen with just one user, at which point it started happeining, ...
It was successfully deployed but reported when someone was accessing the operation.
I only have a bunch of users, so the user should have existed. If it happens again, I will report it. Could it happen because I was logged in already (before the deploy) and then tried to use the same session (I believe that shouldn't cause this issue)? After the next deployment with some more changes and no DB migrations, it started working automatically.
Is there a way I can look deeper into what was happening instead of just the 404. I would have loved to see if there was a query that was failing. I never looked at the DB Logs, let me see if I can still find something there.
Okay I can confirm there are no logs in the DB at that time period.
My first thought was if somehow that DB was inaccessible to the server. I checked if there were any changes to the env variables but nothing changed there. So I didn't know what else to check.
I also verified later by logging on to the DB and made sure the users were there.
On digging in further, you can ignore the above because logging was off on postgres.
I am turning on logging now so that I can figure out what is going on in the future.