Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use consistent error type between doc, logger and error class #5045

Closed
sato11 opened this issue Jul 29, 2022 · 4 comments · Fixed by #5046
Closed

Use consistent error type between doc, logger and error class #5045

sato11 opened this issue Jul 29, 2022 · 4 comments · Fixed by #5046
Labels
documentation Relates to documentation

Comments

@sato11
Copy link
Contributor

sato11 commented Jul 29, 2022

What is the improvement or update you wish to see?

There is an inconsistent use of two of the error codes, OAUTH_CALLBACK_ERROR and CALLBACK_OAUTH_ERROR, of which only the latter is documented as errors: https://next-auth.js.org/errors.

In #5027 (comment), @ThangHuuVu has suggested that we should:

  1. merge docs of the two types mentioned above,
  2. rename them more generic something like CALLBACK_ERROR, and
  3. keep from the same error logged twice.

As a result we can merit from getting rid of subtly discrepant errors, both from docs page and from the source.

In the PR mentioned above, I had attempted to use only CALLBACK_OAUTH_ERROR, but after that I found there is the OAuthCallbackError class. Consequently I'm thinking to use OAUTH_CALLBACK_ERROR so that documentation better represents the implementation.

Is there any context that might help us understand?

After receiving a comment in #5027 I've researched a bit and found some things that might affect the way we sort our docs.

So currently we have in the errors page a headline that says:

oauth_callback_error expected 200 OK with body but no body was returned

while in fact it seems this expected 200 OK with body but no body was returned message never happens in callback phase, but in discovery phase. That is, openid-client emits this message when (and apparently only when) /.well-known/openid-configuration returns no body. cf. https://github.com/panva/node-openid-client/blob/v5.1.8/lib/helpers/process_response.js#L59

In next-auth's side, things described below in order happens

  1. triggers issuer discovery
  2. fails to get authorization url
  3. logs SIGNIN_OAUTH_ERROR withexpected 200 OK with body but no body was returned

So I believe the original content which attributes this error message to OAUTH_CALLBACK_ERROR was not true. I guess associating it with SIGNIN_OAUTH_ERROR can be of help and so I'm planning to create a PR.

Does the docs page already exist? Please link to it.

https://next-auth.js.org/errors

@sato11 sato11 added documentation Relates to documentation triage Unseen or unconfirmed by a maintainer yet. Provide extra information in the meantime. labels Jul 29, 2022
@ThangHuuVu ThangHuuVu removed the triage Unseen or unconfirmed by a maintainer yet. Provide extra information in the meantime. label Jul 31, 2022
@ThangHuuVu
Copy link
Member

Thanks for the detailed issue reporting, @sato11! 🙌

rename them more generic something like CALLBACK_ERROR, and

To be clear, here I suggested throwing CALLBACK_ERROR instead of OAUTH_CALLBACK_ERROR in callback.ts line 196 because at that point we can tell for sure it's no longer an OAuth error 🤔

logger.error("OAUTH_CALLBACK_ERROR", error as Error)

@sato11
Copy link
Contributor Author

sato11 commented Aug 2, 2022

Thanks for the info @ThangHuuVu! I've been unaware of it, but yes, I guess that makes sense. I'll be patching it as well in #5046 👍

@sato11
Copy link
Contributor Author

sato11 commented Aug 2, 2022

Well, let me pause a bit. Do you even want me to include that in #5046 as well actually, or should that be treated as a different issue? I bet it's kind to add it in the error page as well, since CALLBACK_ERROR is not documented in it (which is quite natural). However, I'm not sure what to describe, since I'm still not be able to find the condition on which it can cause CALLBACK_ERROR. In other words, logically I understand your idea is great, while practically I do not understand what information can be of help for those who might be facing CALLBACK_ERROR. Any thoughts?

@ThangHuuVu
Copy link
Member

@sato11 Let's keep it in a separate issue for better clarity 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Relates to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants