502: BAD_GATEWAY from Vercel #825
-
|
Your question I've run out of ways to troubleshoot this error, it seems as if the callback URL What are you trying to do
|
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 5 replies
-
Like https://next-auth-example.now.sh/api/auth/callback/google I'd expected to return https://next-auth-example.now.sh/api/auth/error?error=oAuthCallback if visited in the browser as the request will be incomplete. This should return all configured providers and their callback URLs: It would be interesting to know if another provider (e.g. GitHub) works to understand if the issue is specific to Google (e.g. is it an OAuth callback problem or a database connection problem). As I cannot replicate this issue with the example project, we will probably need access to the repo to delve into this. |
Beta Was this translation helpful? Give feedback.
-
|
I figued out what was going wrong. I saw somewhere that I could block users from signing in if they are not in the the database with this callback code: I thought this would be useful to me as I didn't want users to have account that isn't in sync with the DB. However, it doesn't work as I thought and just rejects the signin everytime, and when deployed to Vercel that |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the follow up! This is really helpful. While we have good coverage for database errors, debugging bugs elsewhere is currently difficult as there currently isn't much support for debugging or error handling outside of the database adapter logic (just something that hasn't been got round to yet) I'm happy to leave this open until we have created an issue to capture improving the debugging for callbacks like this. Did you find a way to do what you wanted (e.g. select by email address in this function) / is "reject if not in database" an option that would be useful? (There are some caveats to doing that, but I can see a good case for it...) |
Beta Was this translation helpful? Give feedback.
-
|
I figured it out! I was using the Email provider and the same thing was happening. Vercel apparently doesn't like JS uncaught exceptions. We were marking our callback as @dasveloper Your code should work if it's rewritten like this: signIn: (user) => {
if (!user.id) {
return Promise.reject(new Error("Sorry, I couldn't find that user");
}
return Promise.resolve(true);
},Note, I removed signIn: (user, account, profile) => {
openDBConnection()
return userIsOnWhitelist(user.email)
.finally(() => {
return knex.destroy()
})
},Here again, I removed the I created this PR to update the docs: #924 |
Beta Was this translation helpful? Give feedback.
-
|
@abcd-ca @dasveloper async signIn(user) {
if (!user.id) {
throw new Error("Sorry, I couldn't find that user");
}
return true)
}Or if you really want an arrow function: signIn: async (user) => {
if (!user.id) {
throw new Error("Sorry, I couldn't find that user");
}
return true)
}@abcd-ca I believe your code should look something like this: async signIn(user, account, profile) {
try {
await openDBConnection()
const allowed = await userIsOnWhitelist(user.email)
await knex.destroy()
return allowed
} catch(error) {
throw error // Throwing the error further to `next-auth`, you will end up on the error page, with the error being a query param.
// Or you can redirect the user to a specific error page in some special cases. note throw is like a return, code after it won't run. So the below code is just an alternative to the code above this comment
if (shouldRedirectSomewhere(error.message)) {
throw "/error-page"
}
throw error // redirect to the default next-auth error page for everything else
}
},But just to be sure, could any of you verify? |
Beta Was this translation helpful? Give feedback.
-
|
@balazsorban44 Thanks for the suggestion. You're right that throwing again from the catch block works while returning Promise.reject() from the catch block does not. Your example works but I think it's better written as, signIn: async (user, account, profile) => {
openDBConnection()
try {
return await userIsOnWhitelist(user.email)
} catch (error) {
throw error
} finally {
await knex.destroy()
}
},In my case I don't actually need to await Also, if one doesn't need the finally block then they can simply do I still think the docs could use a warning as my PR had but I would now re-write it to include the use cases where a try/catch/finally is needed. This 502 is a challenge to debug and the warning could save others time. Let me know and I can update the same PR and resubmit it. |
Beta Was this translation helpful? Give feedback.
-
|
I think your suggested changes to my suggested changes are fine 😅 (I wrote the code from the top of my head, without knowing a lot about the APIs of your libraries, sorry) I might be wrong, but I don't think that it is within our goals to explain JavaScript basics further than not promoting confusing patterns (like async/await combined with Promise.resolve/reject returns) in our documentation. For that, I already have opened a PR (#915), which should hopefully avoid any further misunderstandings when/if merged. To be fair, async/await and Promises are a HARD topic to grasp. I recommend looking at some videos like: I remember these helped me a lot. I guess we could maybe add some useful resource links to the docs in the form of a "Glossary"/"Learning materials" page, or some tutorials. Or mark certain words throughout the docs and link those terms to an MDN equivalent. One thing is sure, we have to do something about it because there seem to be several issues arrising because of this. @nextauthjs/core What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Explaining what I proposed could muddy the docs for everyone who isn't encountering this issue but you're right also that I think we could help people who encounter this problem. Another option could be to do what Vercel is doing and have a catch-all that catches the uncaught exception and renders a helpful error for developers to point them in the right direction |
Beta Was this translation helpful? Give feedback.
-
|
Now that is a good idea, which I think we could accept a PR for, for further discussion. I think the OP's question here has been answered by my answer above, so I am going to mark it as answered. Feel free to open a different discussion under "Ideas", or even open a new PR with your proposed error handling. 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if I'll get around to making a PR for that but this is a good lead https://stackoverflow.com/questions/12571650/catching-all-javascript-unhandled-exceptions |
Beta Was this translation helpful? Give feedback.
@abcd-ca @dasveloper
This should work:
Or if you really want an arrow function:
@abcd-ca I believe your code should look something like this: