TypeError: Cannot destructure property 'statusCode' of 'errors[error.toLowerCase(...)]' as it is undefined.

I’m using next-auth 3.14.5

I’m currently working on a custom credentials provider, and when returning an error, the app fails and shows this error:

(node:72267) UnhandledPromiseRejectionWarning: TypeError: Cannot destructure property 'statusCode' of 'errors[error.toLowerCase(...)]' as it is undefined.
    at error (/Users/jahir/dev/jahir/synaptiko/fe/node_modules/next-auth/dist/server/pages/error.js:51:5)
    at Object.error (/Users/jahir/dev/jahir/synaptiko/fe/node_modules/next-auth/dist/server/pages/index.js:81:34)
    at /Users/jahir/dev/jahir/synaptiko/fe/node_modules/next-auth/dist/server/index.js:222:29
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/Users/jahir/dev/jahir/synaptiko/fe/node_modules/next-auth/dist/server/index.js:52:103)
    at _next (/Users/jahir/dev/jahir/synaptiko/fe/node_modules/next-auth/dist/server/index.js:54:194)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:72267) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 132)
(node:72267) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This is my provider code:

const credentialsProvider: AuthProvider = Providers.Credentials({
  name: 'Synaptikö',
  credentials: {
    email: {
      label: 'Correo electrónico',
      type: 'email',
      placeholder: '[e-mail]',
    },
    password: { label: 'Contraseña', type: 'password' },
  },
  async authorize(credentials): Promise<User | null> {
    try {
      const path = buildBackendUrl('/auth/login');
      const user = post(
        path,
        {
          email: credentials.email,
          password: credentials.password,
        },
        { headers: { accept: '*/*' } },
      )
        .then((user) => {
          console.log('user', user);
          const validUser: User = {};
          return null;
        })
        .catch((e) => {
          const errorMessage = e?.message ?? '';
          // This is where the error happens.
          throw new Error(
            `/?error=${encodeURI(errorMessage)}&email=${encodeURI(
              credentials.email || '',
            )}`,
          );
        });
      return user;
    } catch (e) {
      console.error('try', e);
      return null;
    }
  },
});

[BillBuilt]

Accepted/understood error codes by the /error endpoint are: Default, Configuration, AccessDenied, Verification You probably don’t want to be more specific about the type of error for security reasons anyway. This is not documented anywhere as far as I can tell, could accept a PR, if you are interested.

Ok so I have this question then. Are the only acceptable parameters for the Error those four listed above? We can NOT send a custom error message like the example code states, rather only one of the four error codes?

From https://next-auth.js.org/providers/credentials // throw new Error('error message') // Redirect to error page

Instead it can only be one of these ? throw new Error( ["Default" | "Configuration" | "AccessDenied", "Verification"])

[balazsorban44]

Accepted/understood error codes by the /error endpoint are: Default, Configuration, AccessDenied, Verification You probably don’t want to be more specific about the type of error for security reasons anyway. This is not documented anywhere as far as I can tell, could accept a PR, if you are interested.

If you want better UX for your user, check out the signIn client-side function’s {redirect: false option} https://next-auth.js.org/getting-started/client#using-the-redirect-false-option

We probably shouldn’t crash when a non-standard error is passed to /error though, so I created a fix at #1700