OutofMemory with Node, Fastify, Express server, FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[pczern]

I am having a project where I use meshHttp.handleNodeRequest from createBuiltMeshHTTPHandler on a custom Fastify server.

The code can be viewed here https://github.com/viets-software-club/truffle-ai/blob/2887df8963e396f1cc4450fc16e87c42a716b72c/packages/graphql-gateway/src/server.ts

Replication
there is a commands.txt that includes the commands with environment variables

Codesandbox Link

Failing query:

query TrendingProjects($orderBy: GthbTrendingOrderBy!, $filter: GthbTrendingFilter!, $first: Int, $last: Int, $after: Cursor, $before: Cursor) {
  gthbTrendingCollection(
    filter: $filter
    orderBy: [$orderBy]
    first: $first
    last: $last
    after: $after
    before: $before
  ) {
    edges {
      node {
        gthbRepoId
        gthbRepo {
          gthbRepoId
          gthbRepoName
          gthbRepoDescription
          stargazerCount
          issuesTotalCount
          forkCount
          pullRequestsTotalCount
          gthbRepoUrl
          homepageUrl
          gthbStarHistCollection {
            edges {
              node {
                amount
              }
            }
          }
          gthbForkHistCollection {
            edges {
              node {
                amount
              }
            }
          }
          gthbOwner {
            gthbOwnerType
            gthbOwnerLogin
          }
        }
        dateRange
        lang
      }
    }
    pageInfo {
      hasNextPage
      endCursor
      hasPreviousPage
      startCursor
    }
  }
}

with variables

{
  "orderBy": {
    "dateRange": "AscNullsFirst"
  },
  "filter": {
    "dateRange": {
      "eq": "daily"
    }
	}
}

the heap out of memory is caused here,

const response = await meshHttp.handleNodeRequest(req, {
  req,
  reply
})

I took the example from
https://the-guild.dev/graphql/mesh/docs/getting-started/deploy-mesh-gateway#mesh-as-a-fastify-route

.meshrc.yaml

serve:
  endpoint: /api/graphql
  playground: true
  browser: false
  port: 3001
sources:
  - name: Server
    handler:
      graphql:
        method: POST
        endpoint: "{env.GRAPHQL_SERVER_URL}"
        source: ./schema.js
        operationHeaders:
          Authorization: '{context.headers["authorization"]}'
          authusersid: '{context.headers["authusersid"]}'
        schemaHeaders:
          Authorization: '{context.headers["authorization"]}'
  - name: Supabase
    handler:
      graphql:
        method: POST
        endpoint: "{env.SUPABASE_GRAPHQL_URL}"
        operationHeaders:
          apiKey: "{env.SUPABASE_ANON_KEY}"
          Content-Type: application/json
          Authorization: '{context.headers["authorization"]}'
        schemaHeaders:
          apiKey: "{env.SUPABASE_ANON_KEY}"
          Content-Type: application/json
          Authorization: '{context.headers["authorization"]}'

the stacktrace

<--- Last few GCs --->
[1] 
[1] [6139:0x7fb679600000]   104278 ms: Mark-Compact 4050.4 (4128.8) -> 4031.9 (4126.2) MB, 403.23 / 0.00 ms  (average mu = 0.206, current mu = 0.202) allocation failure; scavenge might not succeed
[1] [6139:0x7fb679600000]   104836 ms: Mark-Compact 4052.1 (4130.6) -> 4034.0 (4128.1) MB, 505.44 / 0.00 ms  (average mu = 0.145, current mu = 0.094) allocation failure; scavenge might not succeed
[1] 
[1] 
[1] <--- JS stacktrace --->
[1] 
[1] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
[1]  1: 0x103338495 node::Abort() [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  2: 0x103338676 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  3: 0x10350706c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  4: 0x103707637 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  5: 0x10370b69c v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  6: 0x10370a11b v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  7: 0x10371eca0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_6::operator()() const [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  8: 0x10371e875 void heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_6>(heap::base::Stack*, void*, void const*) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1]  9: 0x103e61fe8 PushAllRegistersAndIterateStack [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 10: 0x103705040 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 11: 0x1036faaab v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 12: 0x1036fb365 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 13: 0x1036dc10c v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 14: 0x1036cf064 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray(int, v8::internal::AllocationType) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 15: 0x1038a8896 v8::internal::(anonymous namespace)::FastElementsAccessor<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2>>::AddArguments(v8::internal::Handle<v8::internal::JSArray>, v8::internal::Handle<v8::internal::FixedArrayBase>, v8::internal::BuiltinArguments*, unsigned int, v8::internal::(anonymous namespace)::Where) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 16: 0x10356dd35 v8::internal::Builtin_ArrayUnshift(int, unsigned long*, v8::internal::Isolate*) [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 17: 0x103f6f836 Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit [/Users/czer/.nvm/versions/node/v21.1.0/bin/node]
[1] 18: 0x109ae10df 
[1] [nodemon] app crashed - waiting for file changes before starting...

[pczern]

The error is only occurring if used conjunction with a Node.js, Expressjs or Fastify server as in the example. If I do mesh start it works as expected, but I have custom authentication logic so I would need some wrapper.

[ardatan]

First of all I am not sure if you really need Fastify or any other Node specific server with GraphQL Mesh. All those middlewares can be implemented as Mesh plugins in my opinion.
We have integration tests for Fastify and we haven't noticed that kind of issue so far. We need a minimal reproduction on CodeSandbox or a failing test in order to help you.
Fastify tests can be found here;
https://github.com/ardatan/graphql-mesh/blob/master/examples/fastify/tests/fastify.spec.ts

[pczern]

I have created the codesandbox Sandbox
there is a commands.txt containing the build/start command with envs.
the failingquery.graphql and the values in failingquery-values.json.

what I noticed when creating the Sandbox is that it only doesn't work if schema stitching takes place, meaning two graphql sources

[pczern]

@ardatan could you reproduce the issue with the Sandbox?