No maxPoolSize setting?

[gterras]

Hi,

I'm running into ECONNRESET Error in my test, which according to mongo docs is a matter of increasing the maxPoolSize setting.

How ever it doesn't seem to exist in mongodb-memory-server, limit seems to be quite low (~15?), is there a way to tweak this?

[hasezoey]

According to the mongodb documentation maxPoolSize is a driver setting not a server setting, so you need to set in mongodb / mongoose connection, not mongodb-memory-server.

see driver options

limit seems to be quite low (~15?)

The docs say that the default is 100

---

I'm running into ECONNRESET Error in my test, which according to mongo docs is a matter of increasing the maxPoolSize setting.

ECONNRESET can also have different causes which i would need more context of, like situation it happens in and server logs. A example being is that the mongodb server may not be running anymore (for whatever reason).

[gterras]

Thanks for your answer, I can confirm I get the exact same behavior with a local "real" mongo instance so mongo-memory is not at fault here.

It does look like a "simultaneous connections" issue though since since I have a promise.all of calls, and it systematically succeed with X number of calls and systematically fails with X+1 calls (whatever these calls are, it can be a duplication of the same call or different call it doesn't matter). It does work as expect when each call is awaited individually.

Although I've tried overriding min/maxPoolSize in the driver but the result is strictly the same, there must be something I'm missing. I will keep digging.

Thanks anyway!

[hasezoey]

I have a promise.all of calls, and it systematically succeed with X number of calls and systematically fails with X+1 calls

for context, about how many promises / operations are we talking here? depending on the number, the database and / or driver might not be able to keep-up and so "declines" the connections (or is unable to accept in time), though i have not personally encountered this yet.

[gterras]

for context, about how many promises / operations are we talking here?

It's a single test with around 10 calls, each of them doing some pretty light reads on mongo. At 11 this fails consistently. It's worth noting that the app instantiates 2 connections, in real conditions it is 2 mongo instances but the test creates only 1 instance (and 2 databases).

Never seen that in the wild too, our app doesn't have many users but usually typical requests go hard on mongo. But I guess theoretically if users would connect at the exact same nanosecond this could happen, I'm gonna dig into this.

Worth noting that the app is super resilient for non simultaneous (slightly sequential) requests, handling hardcore stress tests successfully.

[gterras]

Hey FYI I finally found the culprit after hours of research forwardemail/supertest#709, turns out supertest doesn't play well with node 20. My case runs flawlessly under node 18, I will try the workarounds suggested in the thread.