Keystone crashes when trying to open item page with too many relationships

[SeanDoyleGit]

Keystone crashes when opening an item page in the admin UI that has too many children in a relationship field. The error that causes keystone to crash is a heap allocation error.

This issue is specific for a client as we need to be able to store thousands of goods per agreement item

Admin UI or keystone should limit the number of children returned so the server doesn't crash and the adminUI does not lag.

this is the error reported by the server

<--- Last few GCs --->
lo[15343:0x10264e000]  1815438 ms: Mark-sweep 1393.3 (1435.8) -> 1387.2 (1435.3) MB, 996.4 / 0.0 ms  (+ 136.9 ms in 75 steps since start of marking, biggest step 6.0 ms, walltime since start of marking 1164 ms) (average mu = 0.130, current mu = 0.028) alloc[15343:0x10264e000]  1816137 ms: Mark-sweep 1393.2 (1435.8) -> 1387.6 (1434.8) MB, 512.5 / 0.0 ms  (+ 151.4 ms in 83 steps since start of marking, biggest step 5.8 ms, walltime since start of marking 697 ms) (average mu = 0.103, current mu = 0.053) alloca

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x223b8a0dbe3d]
Security context: 0x0e838ca9e6e9 <JSObject>
    1: cloneArray(aka cloneArray) [0xe8347e1e949] [~/keystone-cas/node_modules/mongoose/lib/utils.js:~313] [pc=0x223b8af4a74d](this=0x0e83d97826f1 <undefined>,arr=0x0e83fdc03681 <JSArray[6263]>,options=0x0e831fe89829 <Object map = 0xe834acf3fe1>)
    2: clone(aka clone) [0xe83983f7fc9] [~/keystone-cas/...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003c597 node::Abort() [/usr/local/bin/node]
 2: 0x10003c7a1 node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0x1001ad575 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0x100579242 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
 5: 0x10057bd15 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/bin/node]
 6: 0x100577bbf v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0x100575d94 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 8: 0x10058262c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 9: 0x1005826af v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0x100551ff4 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/bin/node]
11: 0x1007da044 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
12: 0x223b8a0dbe3d 
error Command failed with signal "SIGABRT".

[Neo-Zhixing]

This might be related: When I had 60000 items in a relationship field, the browser sends thousands of requests searching for an item that doesn't exist.

This is quite ridiculous. What keystone is doing is literally scraping the entire database with GraphQL to find the element specified.

[stale]

It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)

[micahbule]

Encountering this one as well. Any word on this?

[stale]

It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)

[bladey]

Keystone 5 has officially moved into active maintenance mode as we push towards the next major new version Keystone Next, you can find out more information about this transition here.

In an effort to sustain the project going forward, we're cleaning up and closing old issues such as this one. If you feel this issue is still relevant for Keystone Next, please let us know.