You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hello
We are in the process of migrating fields and types between subgraphs. For this reason, we have many levels of shareble items across the two subrgaphs. Consider this examplen of product-legacy subgraph
We have the main Product interface, and thee individual types that implement that interface (Computer, Monitor and Mouse). Each Product can have metadata values, that are interfaces that point to underlaying types.
Now, we have a very similar schema for product-new subgraph, and once again, we are leveraging @shareble so we can add both types in both subgrapahs (at this point of time, either subgraph can resovle the data)
More or less exactly the same. Only differences is, product-2 subgraph doesn't care about User implementations and uses interfaceObject, and main Product types don't include all the fields.
This works fine, and I get the expected behaviour
Problem is, when we start adding more of this ProductMetadata shared types... (we have more than 10! DropDown, Mutli and Single options, CreditCard, Dates, etc...)... After adding 6 of these types in both subgraphs, the Gateway code fails and blows up NodeJS
<--- Last few GCs --->
[52658:0x7fa930008000] 179699 ms: Scavenge 4010.4 (4111.7) -> 3995.7 (4097.6) MB, pooled: 0 MB, 5.09 / 0.00 ms (average mu = 0.329, current mu = 0.502) allocation failure;
[52658:0x7fa930008000] 182387 ms: Mark-Compact 4011.7 (4112.9) -> 3943.3 (4045.1) MB, pooled: 0 MB, 2676.98 / 0.00 ms (average mu = 0.243, current mu = 0.171) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Adding more than 10 produces a different error actually
{"code":"INTERNAL_SERVER_ERROR","stacktrace":["RangeError: Invalid array length"," at flatCartesianProduct (/app/node_modules/@apollo/query-graphs/dist/graphPath.js:1291:21)"," at advanceSimultaneousPathsWithOperation (/app/node_modules/@apollo/query-graphs/dist/graphPath.js:1245:24)"," at QueryPlanningTraversal.handleOpenBranch (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:151:96)"," at QueryPlanningTraversal.findBestPlan (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:136:18)"," at computeRootParallelBestPlan (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:2012:36)"," at computeRootParallelDependencyGraph (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:2008:12)"," at computePlanInternal (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:1945:33)"," at QueryPlanner.buildQueryPlan (/app/node_modules/@apollo/query-planner/dist/buildPlan.js:1822:24)"," at /app/node_modules/@apollo/gateway/dist/index.js:79:58"," at AsyncLocalStorage.run (node:async_hooks:346:14)"]}}],
And the GW returns a 500 with internal error server
Link to Reproduction
not yet
Reproduction Steps
Use this supergraph with latest version of Gateway:
Issue Description
hello
We are in the process of migrating fields and types between subgraphs. For this reason, we have many levels of shareble items across the two subrgaphs. Consider this examplen of
product-legacy
subgraphWe have the main
Product
interface, and thee individual types that implement that interface (Computer, Monitor and Mouse). Each Product can have metadata values, that are interfaces that point to underlaying types.Now, we have a very similar schema for
product-new
subgraph, and once again, we are leveraging@shareble
so we can add both types in both subgrapahs (at this point of time, either subgraph can resovle the data)More or less exactly the same. Only differences is,
product-2
subgraph doesn't care aboutUser
implementations and usesinterfaceObject
, and mainProduct
types don't include all the fields.This works fine, and I get the expected behaviour
Problem is, when we start adding more of this
ProductMetadata
shared types... (we have more than 10! DropDown, Mutli and Single options, CreditCard, Dates, etc...)... After adding 6 of these types in both subgraphs, the Gateway code fails and blows up NodeJSAdding more than 10 produces a different error actually
And the GW returns a 500 with internal error server
Link to Reproduction
not yet
Reproduction Steps
Use this supergraph with latest version of Gateway:
Launch this query:
with variable
productId: 1234
the process will hang for ever and will eventually run out of memory
The text was updated successfully, but these errors were encountered: