Problems implementing reconnection strategy for mongodb using mongoose on a replica set - node.js

I have an experimental app that uses a NodeJS backend which connects to a mongodb instance using mongoose. Mongodb is configured to run as single-node replica set to give me access to change streams which I use for real-time updates over a websocket connection.
For several reasons I'd like to be able to start the backend without the DB service running and have it connect as soon as it becomes available (primary reason: Docker startup). Also, I would like it to reconnect if the db server becomes unavailable for some reason.
A promising fix for reconnecting to mongodb seems to be https://stackoverflow.com/a/41859984/8447743. However, it does not seem to work in my case. It does work for delayed connection (mongod service starting after app), but gives an error on reconnection:
C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\connection.ts:740
callback(new MongoServerError(document));
^
MongoServerError: Cannot run getMore on cursor 8780071429437342673, which was created in session 993f2cbd-db02-4565-af56-f0c9a88ba012 - 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=, without an lsid
at MessageStream.messageHandler (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\connection.ts:740:20)
at MessageStream.emit (node:events:526:28)
at MessageStream.emit (node:domain:475:12)
at processIncomingData (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\message_stream.ts:167:12)
at MessageStream._write (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\message_stream.ts:64:5)
at writeOrBuffer (node:internal/streams/writable:389:12)
at _write (node:internal/streams/writable:330:10)
at MessageStream.Writable.write (node:internal/streams/writable:334:10)
at Socket.ondata (node:internal/streams/readable:754:22)
at Socket.emit (node:events:526:28) {
ok: 0,
code: 50737,
codeName: 'Location50737',
'$clusterTime': {
clusterTime: Timestamp { low: 2, high: 1650366308, unsigned: true },
signature: { hash: [Binary], keyId: 0 }
},
operationTime: Timestamp { low: 2, high: 1650366308, unsigned: true }
}
[nodemon] app crashed - waiting for file changes before starting...
According to https://www.mongodb.com/docs/manual/reference/command/lockInfo/ I might able to get this lsid that seems to be missing, but I haven't found a way to make that known to mongoose for reconnecting. Is that possible somehow? Is there another way to avoid the error?

Related

Issues connecting to cluster to start database server

I'm follow this guide to setting up an app with a data base
(https://www.mongodb.com/languages/mern-stack-tutorial).
I'm at the step where I have everything installed and an Atlas account set up. I'm trying to connect to my database from VS Code but every time I try it it gives me this
code: 8000,
codeName: 'AtlasError',
connectionGeneration: 0,
[Symbol(errorLabels)]: Set(2) { 'HandshakeError', 'ResetPool' }
All the links that I have looked for related issues on AtlasError or error code 8000s would tell me to not include the <> that is put in with the and in the Atlas URI
mongodb+srv://<username>:<password>#sandbox.jadwj.mongodb.net/employees?retryWrites=true&w=majority. Other suggestions have been to use the username and password that has access to the database rather than the account which have been made certain of.
I tried looking up error labels in the documentation but I don't see anything.
This is the whole output.
Server is running on port: 5000
MongoServerError: bad auth : Authentication failed.
at Connection.onMessage (C:\Users\Alexander Chea\Desktop\Starz\mern\server\node_modules\mongodb\lib\cmap\connection.js:227:30)
at MessageStream.<anonymous> (C:\Users\Alexander Chea\Desktop\Starz\mern\server\node_modules\mongodb\lib\cmap\connection.js:60:60)
at MessageStream.emit (node:events:513:28)
at processIncomingData (C:\Users\Alexander Chea\Desktop\Starz\mern\server\node_modules\mongodb\lib\cmap\message_stream.js:125:16)
at MessageStream._write (C:\Users\Alexander Chea\Desktop\Starz\mern\server\node_modules\mongodb\lib\cmap\message_stream.js:33:9)
at writeOrBuffer (node:internal/streams/writable:392:12)
at _write (node:internal/streams/writable:333:10)
at Writable.write (node:internal/streams/writable:337:10)
at TLSSocket.ondata (node:internal/streams/readable:766:22)
at TLSSocket.emit (node:events:513:28) {
ok: 0,
code: 8000,
codeName: 'AtlasError',
connectionGeneration: 0,
[Symbol(errorLabels)]: Set(2) { 'HandshakeError', 'ResetPool' }
}
Any help would be appreciated, thanks.
Try to remove employees from the URL path because Atlas already knows which database are you using

Truffle migrate --network bsc error: header not found

When trying to run truffle migrate --network bsc, truffle usually (not always) manages to deploy the migrations contract, then fails with an error: header not found.
Error [ERR_UNHANDLED_ERROR]: Unhandled error. ({ code: -32000, message: 'header not found' })
at new NodeError (node:internal/errors:363:5)
at Web3ProviderEngine.emit (node:events:354:17)
at D:\Contracts\novaria\node_modules\web3-provider-engine\index.js:54:14
at afterRequest (D:\Contracts\novaria\node_modules\web3-provider-engine\index.js:148:21)
at D:\Contracts\novaria\node_modules\web3-provider-engine\index.js:174:21
at D:\Contracts\novaria\node_modules\web3-provider-engine\index.js:232:9
at D:\Contracts\novaria\node_modules\async\internal\once.js:12:16
at replenish (D:\Contracts\novaria\node_modules\async\internal\eachOfLimit.js:61:25)
at D:\Contracts\novaria\node_modules\async\internal\eachOfLimit.js:71:9
at eachLimit (D:\Contracts\novaria\node_modules\async\eachLimit.js:43:36)
at D:\Contracts\novaria\node_modules\async\internal\doLimit.js:9:16
at end (D:\Contracts\novaria\node_modules\web3-provider-engine\index.js:211:5)
at Request._callback (D:\Contracts\novaria\node_modules\web3-provider-engine\subproviders\rpc.js:70:28)
at Request.self.callback (D:\Contracts\novaria\node_modules\request\request.js:185:22)
at Request.emit (node:events:365:28)
at Request.<anonymous> (D:\Contracts\novaria\node_modules\request\request.js:1154:10)
at Request.emit (node:events:365:28)
at IncomingMessage.<anonymous> (D:\Contracts\novaria\node_modules\request\request.js:1076:12)
at Object.onceWrapper (node:events:471:28)
at IncomingMessage.emit (node:events:377:35)
at endReadableNT (node:internal/streams/readable:1312:12)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Here's the config for bsc network:
bsc: {
provider: () => { return new HDWalletProvider(mnemonic, `https://bsc-dataseed2.binance.org/`)},
network_id: 56,
confirmations: 10,
timeoutBlocks: 200,
skipDryRun: true,
},
compilers: {
solc: {
version: "0.8.7", // Fetch exact version from solc-bin (default: truffle's version)
// docker: true, // Use "0.5.1" you've installed locally with docker (default: false)
settings: { // See the solidity docs for advice about optimization and evmVersion
optimizer: {
enabled: true,
runs: 200
},
Deploying to testnet and development works without issue. I have in the past deployed to bsc with truffle (been a while though). I've tried changing RPC urls, and messed around with timeout and confirmations (pretty sure that doesn't make a difference for this error). After searching the internet for solutions, the only answer that seems to have worked for people is to change the RPC, but I haven't had any luck with that. Does anyone have any suggestions?
I had the same problem today. Fixed it by using the Websocket endpoint wss://bsc-ws-node.nariox.org:443 from the smart chain docs https://docs.binance.org/smart-chain/developer/rpc.html

CentOS + Node.js (v8.15.0) + Sequelize (v4.38.0) to Azure SQL Intermittent Connection Issues

On our production Azure Hosted CentOS API server we are having intermittent Sequelize connection issues to our Azure SQL database.
Our connection settings are as follows:
const sequelize = new Sequelize(dbDatabase, dbUser, dbPassword, {
host: dbHost,
dialect: 'mssql',
operatorsAliases: false,
pool: {
max: 5092,
min: 0,
acquire: 10000,
idle: 10000,
evict: 500,
},
dialectOptions: {
encrypt: false, // Use this if you're on Windows Azure
requestTimeout: 60000 * 2,
},
}
We have also set the ulimit for open files by the process to the system max.
We are using PM2 to run the server.
The two errors that sometimes appear in our logs roughly every 10-20 minutes are:
SequelizeConnectionError
at Connection.connection.on (/home/AZ-admin/XXX/node_modules/sequelize/lib/dialects/mssql/connection-manager.js:75:16)
at emitNone (events.js:106:13)
at Connection.emit (events.js:208:7)
at Connection.cleanupConnection (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:568:16)
at Connection.enter (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:1961:12)
at Connection.transitionTo (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:993:26)
at Connection.socketEnd (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:1036:12)
at Socket.<anonymous> (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:877:18)
at emitNone (events.js:111:20)
at Socket.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:139:11)
at process._tickCallback (internal/process/next_tick.js:181:9)
or
SequelizeHostNotFoundError: Failed to connect to xxx-prod.database.windows.net:1433 - getaddrinfo ENOTFOUND xxx-prod.database.windows.net
at Connection.connection.on.err (/home/XXX/node_modules/sequelize/lib/dialects/mssql/connection-manager.js:98:22)
at emitOne (events.js:116:13)
at Connection.emit (events.js:211:7)
at Connection.socketError (/home/XXX/node_modules/tedious/lib/connection.js:1016:14)
at /home/XXX/node_modules/tedious/lib/connection.js:861:25
at GetAddrInfoReqWrap.callback (/home/XXX/node_modules/tedious/lib/connector.js:69:18)
at GetAddrInfoReqWrap.onlookupall [as oncomplete] (dns.js:79:17)
We think this could anything from an issue with connections/files being opened and not closed and reaching a limit to a problem with our DNS looking up the domain name.
It does appear to be somewhat tied to an increase in traffic, but the correlation is not 100% clear.
I saw your sample code missing options in dialectOptions.
It should be like below.
"dialectOptions": {
options: {
encrypt: true,
}
}
Before I have create a sample project to connect mssql and mysql. Hope it can help you. For more details, please check my answer in below post.
Azure Database for MySQL - webapp nodejs

Connecting to an Azure Redis Cluster using node.js ioredis not working

I've been trying to connect to a Redis three node cluster in Azure using ioredis.
When I connect using the Redis.Cluster constructor:
new Redis.Cluster(['host.redis.cache.windows.net', 6380], {
scaleReads: 'all',
slotsRefreshTimeout: 2000,
redisOptions: {
password: 'some-secret',
tls: true as any
},
});
The error I get is:
2020-06-04T13:05:41.787Z ioredis:cluster getting slot cache from 127.0.0.1:6380
2020-06-04T13:05:41.788Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: [empty] -> wait
2020-06-04T13:05:41.788Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: wait -> connecting
2020-06-04T13:05:41.788Z ioredis:redis queue command[127.0.0.1:6380 (ioredisClusterRefresher)]: 0 -> cluster([ 'slots' ])
2020-06-04T13:05:41.790Z ioredis:connection error: Error: connect ECONNREFUSED 127.0.0.1:6380
2020-06-04T13:05:41.791Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: connecting -> close
2020-06-04T13:05:41.791Z ioredis:connection skip reconnecting because `retryStrategy` is not a function
2020-06-04T13:05:41.791Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: close -> end
2020-06-04T13:05:41.792Z [auth-middleware] Redis error { ClusterAllFailedError: Failed to refresh slots cache.
at tryNode (/app/node_modules/ioredis/built/cluster/index.js:359:31)
at /app/node_modules/ioredis/built/cluster/index.js:376:21
at duplicatedConnection.cluster.utils_2.timeout (/app/node_modules/ioredis/built/cluster/index.js:624:24)
at run (/app/node_modules/ioredis/built/utils/index.js:156:22)
at tryCatcher (/app/node_modules/standard-as-callback/built/utils.js:11:23)
at promise.then (/app/node_modules/standard-as-callback/built/index.js:30:51)
at process._tickCallback (internal/process/next_tick.js:68:7)
lastNodeError:
Error: Connection is closed.
at close (/app/node_modules/ioredis/built/redis/event_handler.js:179:25)
at TLSSocket.<anonymous> (/app/node_modules/ioredis/built/redis/event_handler.js:150:20)
at Object.onceWrapper (events.js:277:13)
at TLSSocket.emit (events.js:194:15)
at _handle.close (net.js:600:12)
at TCP.done (_tls_wrap.js:388:7) }
When I connect using a non-cluster Redis connection:
new Redis(6380, 'host.redis.cache.windows.net', { password: 'some-secret' });
The error I get is:
020-06-04T15:04:08.609Z ioredis:redis status[10.211.x.x:6380]: connecting -> connect
2020-06-04T15:04:08.614Z ioredis:redis write command[10.211.x.x:6380]: 0 -> auth([ 'some-secret' ])
2020-06-04T15:04:08.616Z ioredis:redis write command[10.211.x.x:6380]: 0 -> info([])
2020-06-04T15:05:16.114Z ioredis:connection error: Error: read ECONNRESET
2020-06-04T15:05:16.115Z [auth-middleware] Redis error { Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }
As you can see it is using TLS on port 6380. Azure provides me with one host+port combination and two different access-keys (primary/seconday) - which I find weird, which access-key should I use? Also I'm not sure if I should be connecting in Cluster mode, but I'd prefer to to gain the benefits of clustering. When I do it appears it tries to find the slots at 127.0.0.1:6380 which is probably not correct.
In Azure's quickstart they connect using node_redis with:
var redis = require("redis");
// Add your cache name and access key.
var client = redis.createClient(6380, process.env.REDISCACHEHOSTNAME,
{auth_pass: process.env.REDISCACHEKEY, tls: {servername: process.env.REDISCACHEHOSTNAME}});
I was hoping someone here would have come across the same issue and solved it.
Thanks!
Okay I've managed to connect to Azure Redis Cluster using a non-tls connection:
new Redis.Cluster(['host.redis.cache.windows.net', 3679], {
scaleReads: 'all',
slotsRefreshTimeout: 2000,
redisOptions: {
password: 'some-secret',
},
})
For some reason connecting to 6380 with TLS enabled does not work.

Mongoose bulkWrite - Wrong type for 'q'

For my test suite, I want to bulkWrite test info in the database, and then bulk delete any of the test info entered throughout the test to come back to a clean slate. I do so by running a bulkWrite on the db to which I pass the content of a JSON file loaded via nodeJS's require statement.
The problem is that for the dataset
[ { deleteOne: { username: 'test-author' } } ]
passed to models[key].collection.bulkWrite(action[key]), where key is the name of the model of interest and action is the JSON file,I get the following error:
{ MongoError: Wrong type for 'q'. Expected a object, got a null.
at Function.MongoError.create (/var/www/website/server/node_modules/mongodb-core/lib/error.js:31:11)
at /var/www/website/server/node_modules/mongodb-core/lib/connection/pool.js:483:72
at authenticateStragglers (/var/www/website/server/node_modules/mongodb-core/lib/connection/pool.js:429:16)
at Connection.messageHandler (/var/www/website/server/node_modules/mongodb-core/lib/connection/pool.js:463:5)
at Socket.<anonymous> (/var/www/website/server/node_modules/mongodb-core/lib/connection/connection.js:339:20)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:548:20)
name: 'MongoError',
message: 'Wrong type for \'q\'. Expected a object, got a null.',
ok: 0,
errmsg: 'Wrong type for \'q\'. Expected a object, got a null.',
code: 14,
codeName: 'TypeMismatch' }
I have done some research and have been unable to find a solution to this problem. The error itself is pretty meaningless, so I can't grasp much out of it. Any idea how to solve the problem?
Any help would be greatly appreciated!
Cheers!
As per the MongoDB API, the deleteOne, deleteMany, updateOne, updateMany, replaceOne, and replaceMany operation requires to have a property filter which acts as the filter for the query.
However Mongoose's API shows the following (mistaken) example:
Character.bulkWrite([
...
{
deleteOne: {
{ name: 'Eddard Stark' }
}
}
]).then(handleResult);
Hence, the data sent over changes from:
[{
"deleteOne": { "username": "test-author" }
}]
to
[{
"deleteOne": { "filter": { "username": "test-author" }}
}]
I'll make sure to pass the message along to the mongoosejs dev group.

Resources