Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error that hasn't been happening before (started 2 days ago) #11200

Closed
xMyThoLoGyx opened this issue Jan 8, 2022 · 8 comments
Closed

Error that hasn't been happening before (started 2 days ago) #11200

xMyThoLoGyx opened this issue Jan 8, 2022 · 8 comments
Labels
docs This issue is due to a mistake or omission in the mongoosejs.com documentation
Milestone

Comments

@xMyThoLoGyx
Copy link

xMyThoLoGyx commented Jan 8, 2022

I've been having this error pop up on me recently :

MongooseError: Operation importantids.findOne() buffering timed out after 10000ms
at Timeout. (/root/disgo/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:198:23)
at listOnTimeout (node:internal/timers:557:17)
at processTimers (node:internal/timers:500:7)

I successfully connect to the database and interact with it in my app, but recently, it keeps doing that error at random times and will not stop until I restart the app.

Mongoose version : 5.13.7 (won't update using npm update)

@vkarpov15 vkarpov15 added the needs clarification This issue doesn't have enough information to be actionable. Close after 14 days of inactivity label Jan 10, 2022
@vkarpov15
Copy link
Collaborator

Not enough information for us to repro. Please provide a code sample that demonstrates this issue.

@fakelag
Copy link

fakelag commented Jan 11, 2022

Can second this. For me the issue seems to be that the new mongoose version (we are using 6.1.6) tries to resolve the replica set hostname by itself and throws getaddrinfo ENOTFOUND mongod-0 (mongod-0 is resolvable from the mongodb server, but not from connecting client). However previous versions and mongosh connects fine. It can not connect and so buffered operations fail with timeout.

Fixed by setting directConnection: true in mongoose connection options like so. It feels like previous versions potentially had the connection default to direct connect or something similar?

    const connectionPromise = mongoose.connect(mongoUrl, {
        directConnection: true,
    });

@GCastilho
Copy link
Contributor

Not enough information for us to repro. Please provide a code sample that demonstrates this issue.

I think I can provide more info on this

I have a replica set configured on my raspberry pi, on a different machine, the rs was initiated using:

rs.initiate({
  _id : "rs0",
    members: [
      { _id: 0, host: "127.0.0.1:27017" },
    ]
})

On mongodb 5.13.14, the last from major 5, the 127.0.0.1 was correctly resolved to the rpi ip on the network, but updating to any version post 6 and it tries to connect on 127.0.0.1 from my machine. Here's some logs:

MongooseServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017
    at NativeConnection.Connection.openUri (C:\repo\node_modules\mongoose\lib\connection.js:797:32)
    at C:\repo\node_modules\mongoose\lib\index.js:341:10
    at C:\repo\node_modules\mongoose\lib\helpers\promiseOrCallback.js:32:5
    at new Promise (<anonymous>)
    at promiseOrCallback (C:\repo\node_modules\mongoose\lib\helpers\promiseOrCallback.js:31:10)
    at Mongoose._promiseOrCallback (C:\repo\node_modules\mongoose\lib\index.js:1167:10)
    at Mongoose.connect (C:\repo\node_modules\mongoose\lib\index.js:340:20)
    at Object.<anonymous> (C:\repo\src\db\mongoose.ts:13:10)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Module.m._compile (C:\Users\Gabriel\AppData\Roaming\npm\node_modules\ts-node\src\index.ts:1365:23) {
  reason: TopologyDescription {
    type: 'ReplicaSetNoPrimary',
    servers: Map(1) { '127.0.0.1:27017' => [ServerDescription] },
    stale: false,
    compatible: true,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    setName: 'Raspberry-PI',
    maxSetVersion: 1,
    maxElectionId: new ObjectId("7fffffff0000000000000043"),
    commonWireVersion: 9,
    logicalSessionTimeoutMinutes: undefined
  }
}

I've tested on the same repositório, only changing from 5.13.14, 6.0 and 6.1.6 (latest)

Hope it helps

@vkarpov15
Copy link
Collaborator

@fakelag take a look at the docs on replica set hostnames. The "tries to resolve the replica set hostname by itself" behavior is definitely not new in 6.1.6, we've had that behavior since 5.13 at least, if you had useUnifiedTopology: true. What version are you upgrading from?

@GCastilho sounds like you where running with useUnifiedTopology: false in 5.x. See replica set hostnames docs. In 6.x, you need to make sure that the replica set member hostnames are something that your app server can resolve.

@fakelag
Copy link

fakelag commented Jan 20, 2022

@fakelag take a look at the docs on replica set hostnames. The "tries to resolve the replica set hostname by itself" behavior is definitely not new in 6.1.6, we've had that behavior since 5.13 at least, if you had useUnifiedTopology: true. What version are you upgrading from?

We have had useUnifiedTopology: true in previous versions of mongoose (the latest before upgrade was 5.13.6) and the connection has worked every time with that version. Only upon upgrading to the newest version the problem started occurring, and as I said setting directConnect to true has fixed the issue.

After upgrading, we also do not supply useUnifiedTopology: true anymore as it defaults to true, but even setting it to true manually doesn't have any effect. Again, only directConnect: true fixes the issue

@vkarpov15 vkarpov15 added this to the 6.1.11 milestone Jan 24, 2022
@vkarpov15 vkarpov15 added needs repro script Maybe a bug, but no repro script. The issue reporter should create a script that demos the issue and removed needs clarification This issue doesn't have enough information to be actionable. Close after 14 days of inactivity labels Jan 24, 2022
@GO-DIE
Copy link

GO-DIE commented Feb 13, 2022

@fakelag take a look at the docs on replica set hostnames. The "tries to resolve the replica set hostname by itself" behavior is definitely not new in 6.1.6, we've had that behavior since 5.13 at least, if you had useUnifiedTopology: true. What version are you upgrading from?

@GCastilho sounds like you where running with useUnifiedTopology: false in 5.x. See replica set hostnames docs. In 6.x, you need to make sure that the replica set member hostnames are something that your app server can resolve.

I also encountered the same problem when upgrading from version 5.13.8 to version 6.0.0. Has the problem been resolved?

@GO-DIE
Copy link

GO-DIE commented Feb 13, 2022

I also encountered the same problem when upgrading from version 5.13.8 to version 6.0.0. Has the problem been resolved?

@vkarpov15
Copy link
Collaborator

I took a closer look and I don't see anything to indicate this is anything other than a case of replica set hostname inconsistency, which is documented and expected behavior in the MongoDB Node driver. You need to make sure that the self-reported hostname on the machine that's hosting your MongoDB server is resolvable from your application server.

@vkarpov15 vkarpov15 removed this from the 6.2.3 milestone Feb 20, 2022
@vkarpov15 vkarpov15 removed the needs repro script Maybe a bug, but no repro script. The issue reporter should create a script that demos the issue label Feb 20, 2022
@vkarpov15 vkarpov15 added this to the 6.2.3 milestone Feb 20, 2022
@vkarpov15 vkarpov15 added the docs This issue is due to a mistake or omission in the mongoosejs.com documentation label Feb 20, 2022
vkarpov15 added a commit that referenced this issue Feb 20, 2022
…or message and info about `err.reason.servers`

Fix #11200
@Automattic Automattic locked and limited conversation to collaborators Mar 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
docs This issue is due to a mistake or omission in the mongoosejs.com documentation
Projects
None yet
Development

No branches or pull requests

5 participants