MongoDB: `?connectTimeoutMS=value` seemingly has no effect on query/migrate engine

Bug description

When running prisma db push command agains non-existing server, connection seems to always timeout after 30s. Docs suggest connectTimeoutMS query parameter can be used for changing this timeout, but actually, it does not seem to be the case.

How to reproduce

1. Copy provided schema
2. Ensure mongo is NOT running on provided host/port.
3. Run time prisma db push against the schema
4. Command will timeout after 30s:

Prisma schema loaded from prisma/schema.prisma
Datasource "db"
Error: MongoDB error
Server selection timeout: No available servers. Topology: { Type: Unknown, Servers: [ { Address: nothere:12345, Type: Unknown, Error: failed to lookup address information: nodename nor servname provided, or not known }, ] }
   0: migration_core::state::SchemaPush
             at migration-engine/core/src/state.rs:349

pnpm prisma db push  0.69s user 0.18s system 2% cpu 30.557 total

Expected behavior

Same timeout error, but after 1 second as specified by connection string.

Prisma information

Prisma schema:

generator client {
  provider        = "prisma-client-js"
}

datasource db {
  provider = "mongodb"
  url      = "mongodb://nothere:12345/db?connectTimeoutMS=1000"
}

model User {
  id String @id @map("_id")
}

Environment & setup

• OS: macOS
• Database: MongoDB
• Node.js version: 16.15.1

Prisma Version

4.2.0-dev

[tomhoule]

Copying my reaction from slack: Hmm, first time I read about this param. When I grep for it in prisma-engines, I have 0 matches, so either it’s implemented in the mongo driver or we documented something that doesn’t exist.

[patrickfreed]

The timeout being hit here is serverSelectionTimeoutMS, which has a default value of 30 seconds. This timeout governs how long the MongoDB driver will wait until a suitable server is discovered when attempting an operation, which seems closer to what you intended. connectTimeoutMS, on the other hand, governs only how long connection establishment takes (i.e. it specifies how long we can wait for establishment to take before we can confidently say the server is down).

What’s going on here is likely that the monitor task is attempting and failing to establish a connection to the non-existent server quickly and repeatedly while the operation waits for the server to be discovered, with connectTimeoutMS never actually coming into play.

To make this speedier, you can specify a lower serverSelectionTimeoutMS.