nextauthjs / nextauthjs/next-auth

Unhandled errors on the edge runtime. (Not present in prod!)

Open
#9,869 6 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug triage
Dominant language
TypeScript
Stars
28.4k
Forks
4k
PR merge metrics
No merged PRs in 30d

Description

Environment

System:
OS: macOS 14.0
CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Memory: 598.19 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 21.5.0 - ~/.nvm/versions/node/v21.5.0/bin/node
npm: 10.2.4 - ~/.nvm/versions/node/v21.5.0/bin/npm
pnpm: 8.8.0 - ~/Library/pnpm/pnpm
Browsers:
Chrome: 121.0.6167.85
Safari: 17.0
npmPackages:
next: ^14.0.4 => 14.1.0
next-auth: 5.0.0-beta.5 => 5.0.0-beta.5
react: 18.2.0 => 18.2.0

Reproduction URL

https://github.com/ypanagidis/authjs-unhandled-errrs-edge

Describe the issue

I noticed that if the signIn callback returns false there is a TypeError (TypeError: immutable) (on top of the AuthorizedCallbackError) only on the edge runtime. This only happens when the runtime is set to edge on the api route handler. By just commenting that line (src/app/api/auth/[...next-auth]/route.ts line two) the same flow redirects to the default error page and there is no TypeError error. The issue is not present in production, just on dev.

How to reproduce

To replicate the issue just pnpm install and add the Discord provider details to the .env file. (You can rename the .env.example). I chose Discord for this replication repo but I have reproduced the same error using the Google provider as well so feel free to use whichever one is easiest for you. It dosen't seem to be provider specific/related at all.

Expected behavior

When the signIn callback returns false there should be a redirect to the error page, which happens only when not using the edge runtime.
Some notes:

  • I also noticed the same error on-top of other AuthErrors anytime the auth flow breaks, including when getting an OAuthAccountNotLinked error.
  • I did not include an adaptor or database in this repo for ease of reproduction but I have tested it with the planetscale databasejs HTTP connection (which is edge compatible) using the drizzle adapter (also edge compatible) and everything worked fine however the errors persisted
  • I also tried starting the authentication flow using the signIn function from "next-auth/react" inside a client component and had the same results.
  • I chose to make a custom error page but the same error and behaivour appears when using the default one and leaving the pages object in the auth config file empty/null
  • Here there is no middleware but I am also getting the same erros when there is middleware used (tried importing straight from auth.ts and also from the split method to not load the adaptor using a separate auth.config.ts file)
  • The same errors appear also on next-auth 5.0.0-beta.4
  • This is my first ever issue and since I'm relative new to the space I apologise in advance if I didn't report it correctly.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the reproduction repository, run pnpm install, configure a provider in .env, and compare the edge and non-edge versions of src/app/api/auth/[...next-auth]/route.ts, especially line two. Reproduce a failed signIn callback or OAuthAccountNotLinked flow and trace the resulting error handling. Done means the edge development runtime redirects to the error page without the additional TypeError.

Written by the indexing model from the issue text.

Assessment

Tech stack
next.js, node.js, react, typescript
Domain
api, authentication, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.