Hi,
I can see this is a client-side memory exception. You are dealing with a huge amount of data here. The NEST library itself will cause allocations for each search, but those should be short-lived in most cases and collected during the next gen-0 GC. At scale though, with a tight search loop, it's possible those are not being collected quickly enough to release the memory. What .NET runtime are you using, how much memory does your system have available, what OS are you using and how are you running the app (i.e. is it in a constrained environment such as Docker)?
How complex is your Call type? Each result will allocate an instance of that. Also, after you receive the 5,000 results, are you holding onto those beyond each search (in a List for example) or processing them before performing the next scrolled search?
Which version of NEST are you using? We made some changes to memory pooling behaviour in recent releases.
To narrow down the cause, I'd recommend you perform some memory profiling to determine which objects are consuming the most memory and living the longest. If you are able to collect a memory dump from the crashed application, that would be most useful. This will help us identify what is contributing to the OOM exception.
Cheers,
Steve