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

Intermittent Failure: request to http://localhost:3000/api/auth/session failed, reason: read ECONNRESET #4553

Closed
mopatches opened this issue May 11, 2022 · 14 comments
Labels
triage Unseen or unconfirmed by a maintainer yet. Provide extra information in the meantime.

Comments

@mopatches
Copy link

mopatches commented May 11, 2022

Environment

System:
    OS: Linux 5.17 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 18.63 GB / 31.20 GB
    Container: Yes
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.18 - /usr/local/bin/yarn
    npm: 8.5.0 - /usr/local/bin/npm
  npmPackages:
    next: ^12.1.6 => 12.1.6 
    next-auth: ^4.3.4 => 4.3.4 
    react: 17.0.2 => 17.0.2 

Reproduction URL

None

Describe the issue

Hello! My NextJS app works great most of the time, but intermittently fails on /api calls due to an exception in next-auth. The exception happens in dev and prod/precompiled mode. I haven't found a consistent repro to cause the exception:

wait  - compiling /api/.../...
wait  - compiling...
event - compiled client and server successfully in 199 ms (867 modules)
[next-auth][error][CLIENT_FETCH_ERROR] 
https://next-auth.js.org/errors#client_fetch_error request to http://localhost:3000/api/auth/session failed, reason: read ECONNRESET {
  error: {
    message: 'request to http://localhost:3000/api/auth/session failed, reason: read ECONNRESET',
    stack: 'FetchError: request to http://localhost:3000/api/auth/session failed, reason: read ECONNRESET\n' +
      '    at ClientRequest.<anonymous> (/workspace/node_modules/next/dist/compiled/node-fetch/index.js:1:64142)\n' +
      '    at ClientRequest.emit (node:events:526:28)\n' +
      '    at ClientRequest.emit (node:domain:475:12)\n' +
      '    at Socket.socketErrorListener (node:_http_client:442:9)\n' +
      '    at Socket.emit (node:events:526:28)\n' +
      '    at Socket.emit (node:domain:475:12)\n' +
      '    at emitErrorNT (node:internal/streams/destroy:157:8)\n' +
      '    at emitErrorCloseNT (node:internal/streams/destroy:122:3)\n' +
      '    at processTicksAndRejections (node:internal/process/task_queues:83:21)',
    name: 'FetchError'
  },
  path: 'session',
  header: {
    host: 'localhost:3000',
    connection: 'keep-alive',
    pragma: 'no-cache',
    'cache-control': 'no-cache',
    'sec-ch-ua': '" Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"',
    dnt: '1',
    'sec-ch-ua-mobile': '?0',
    'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.41 Safari/537.36',
    'sec-ch-ua-platform': '"Linux"',
    accept: '*/*',
    'sec-fetch-site': 'same-origin',
    'sec-fetch-mode': 'cors',
    'sec-fetch-dest': 'empty',
    referer: 'http://localhost:3000/...',
    'accept-encoding': 'gzip, deflate, br',
    'accept-language': 'en-US,en;q=0.9',
    cookie: '_xsrf=...'
  },
  message: 'request to http://localhost:3000/api/auth/session failed, reason: read ECONNRESET'
}

The browser sees this exception as a 401, but it able to retry and the second request works without issue.

Any guidance on what to try would be very welcome. Thank you!

How to reproduce

Calling /api routes from within a setInterval seems to trigger the exception every few minutes. The exception appears more likely to trigger in dev mode with the server recompiling server-side code often.

Expected behavior

No exception, or the ability to catch and retry server-side.

@mopatches mopatches added the triage Unseen or unconfirmed by a maintainer yet. Provide extra information in the meantime. label May 11, 2022
@sudo-jaa
Copy link

sudo-jaa commented May 12, 2022

We've been having the same issue. As far as I can tell we only start getting this error after upgrading next to v12 In our case we're on 12.1.0, so a bit behind your example but the error is the same. No such issue when rolling back to versions of our app that use next v11.
Hopefully there's something useful in that!

Out of interest, are you using swc to compile?

@mopatches
Copy link
Author

Hi @sudo-jaa! Yes, we're using swc. It's so fast :)

@sudo-jaa
Copy link

@mopatches I agree - SWC is definitely a great tool! Though there do seem to be situations where it can cause some issues. I remember our first stab at transition to nextjs 12 and SWC from babel had some issues where compilation was panicking due to a recursion depth limit - at least during the minification process. They did end up managing to fix it a few updates in, but it makes me think that it might, under certain circumstances, output imperfect transpiled / minified code.

That said, the people who maintain next and swc are way smarter than I could ever hope to be, so this isn't an accusation or anything that there might be a bug there! But it might be an interesting thread to pull to see if it resolves your issue. If falling back to babel/next 11 solves your issue, then that's probably really useful information to be able to supply to the maintainers of next-auth. If not then we could rule it out. Like I said - in our case this issue only started after bumping to nextjs 12 🤔

@huksley
Copy link

huksley commented May 13, 2022

I have the same issue. I also had it on NextJS 11 but less frequent.

I have custom _document.tsx and _app.tsx with SessionProvider.

@stevenspads
Copy link

stevenspads commented May 19, 2022

I'm having a similar issue locally on the same endpoint (http://localhost:3000/api/auth/session), but the error reason is socket hang up. It's intermittent and difficult to debug. Any ideas?

[next-auth][error][CLIENT_FETCH_ERROR] 
https://next-auth.js.org/errors#client_fetch_error request to http://localhost:3000/api/auth/session failed, reason: socket hang up {
  error: {
    message: 'request to http://localhost:3000/api/auth/session failed, reason: socket hang up',
    stack: 'FetchError: request to http://localhost:3000/api/auth/session failed, reason: socket hang up\n' +    
      '    at ClientRequest.<anonymous> 

Environment

System:
    OS: Windows 10 10.0.19041
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    Memory: 43.56 GB / 63.93 GB
  Binaries:
    Node: 14.17.5 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.14 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 101.0.4951.54
    Edge: Spartan (44.19041.423.0), Chromium (101.0.1210.47)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    next: 12.0.10 => 12.0.10
    next-auth: ^4.3.4 => 4.3.4
    react: 17.0.2 => 17.0.2

I opened a separate issue #4584

@simonecervini
Copy link
Contributor

I'm having a similar problem, I opened a separate issue: #4590

@royletron
Copy link

@simonecervini , @stevenspads, @huksley, @mopatches can I ask if you guys are using next-auth v4 or v3? Just trying to work out where this could possibly be going wrong!

@mopatches
Copy link
Author

Hello @royletron! I'm using next-auth v4 (currently v4.3.4).

@royletron
Copy link

@mopatches is your adapter Prisma?

@simonecervini
Copy link
Contributor

Hello @royletron! I'm using v4.3.4 with mongodb-adapter v1.0.0

@mopatches
Copy link
Author

@royletron yes, my adapter is Prisma.

@stevenspads
Copy link

@royletron I'm using next-auth version 4 and my adapter is Prisma.

@huksley
Copy link

huksley commented May 29, 2022

I am using nextJS 12, next-auth 4
I think it is related to using getUserSession() on the server side, as it makes additional request to /api/auth/session endpoint.

I am using a hack from #3330 (comment)
to avoid having that additional request which is not necessary IMO

It is nice to have a unified API but server-side implementation should tap directly into backend without extra HTTP hop.

@balazsorban44
Copy link
Member

Unfortunately, this does not sound like we can do much about it as there is no clear reproduction. #4116 might help with this in the future, depending on your use case, but without code, it's hard to tell if that's even a related problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Unseen or unconfirmed by a maintainer yet. Provide extra information in the meantime.
Projects
None yet
Development

No branches or pull requests

7 participants