vercel / vercel/next.js

Using `use` in a Server Component freezes

Open
#42,469 17 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Linting
Dominant language
JavaScript
Stars
142k
Forks
32.4k
Avg merge
2d 14h
Merged PRs (30d)
351

Description

Verify canary release
  • I verified that the issue exists in the latest Next.js canary release
Provide environment information

---->npx --no-install next info

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64
Binaries:
  Node: 16.11.1
  npm: 8.18.0
  Yarn: 1.22.17
  pnpm: N/A
Relevant packages:
  next: 13.0.2
  eslint-config-next: 13.0.0
  react: 18.2.0
  react-dom: 18.2.0
What browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

n/a

Describe the Bug

I have a pretty rudimentary RSC demo coded up here:

https://github.com/arackaf/next-13-data-fetching-blog-post/blob/feature/use-bug-repro/app/Todos.tsx

When I unwrap the promise in the component using the data using use then Node freezes up. I see about 15+ Node tasks in activity monitor, with one of them at about 150%. Using await works fine.

Eventually, after killing the Next watch, I get this

<--- Last few GCs --->

[5793:0x7f8b54a00000] 256154 ms: Mark-sweep 4018.6 (4130.7) -> 4003.6 (4126.9) MB, 5916.0 / 0.8 ms (average mu = 0.093, current mu = 0.015) allocation failure scavenge might not succeed
[5793:0x7f8b54a00000] 256564 ms: Scavenge 4019.9 (4127.2) -> 4005.8 (4127.2) MB, 359.2 / 0.5 ms (average mu = 0.093, current mu = 0.015) allocation failure

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x101978545 node::Abort() (.cold.1) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
2: 0x100679a49 node::Abort() [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
3: 0x100679bbf node::OnFatalError(char const*, char const*) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
4: 0x1007f9387 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
5: 0x1007f9323 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
6: 0x10099aa35 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
7: 0x10099ea7d v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
8: 0x10099b35d v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
9: 0x10099887d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
10: 0x1009a5bb0 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
11: 0x1009a5c31 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
12: 0x100972d87 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
13: 0x100d2855e v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]
14: 0x1010d1e99 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/node]

Expected Behavior

Use should work the same as await

Link to reproduction

https://github.com/arackaf/next-13-data-fetching-blog-post/blob/feature/use-bug-repro/app/Todos.tsx

To Reproduce

Clone that repo at that branch, and run. Swap the use calls out for the commented out await calls (after clearing the rogue Node processes) to see it work.

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

Clone the linked reproduction repository at the feature/use-bug-repro branch and start with app/Todos.tsx. Run it with the use calls, then compare with the commented-out await calls after clearing the lingering Node processes. Done means use no longer freezes or exhausts the Node heap and behaves like await.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, next.js, node.js, react
Domain
backend, frontend, web-dev
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.