Cluster UnhandledPromiseRejectionWarning #883
Comments
|
You can see the command that caused the UnhandledPromiseRejectionWarning by enabling new Cluster([], { showFriendlyErrorStack: true })It's also possible that the command were sent from ioredis internal, if that is the case, we'll figure out a way to solve it. |
|
@luin thanks for the reply. The I couldn't figure out why that's happening, but it seems like Anyway, I worked around that using the chrome inspector and I see the friendly stack trace reporting the callsite of the This code is running during an http request, and I've confirmed that the callsite is only executed once during a request. Yet, I count 16 of these unhandled rejections for every request. If I pause on uncaught exceptions with inspector, it pauses 17 times on Are those numbers a clue as to what might be happening? |
|
I put together a minimal reproduction: docker-compose.yaml: version: '3.7'
services:
web:
image: node:dubnium-alpine
user: node
working_dir: /home/node/app
depends_on:
- redis
environment:
DEBUG: 'ioredis:*'
NODE_ENV: dev
ports:
- '3000:3000'
- '9222:9222'
volumes:
- .:/home/node/app
init: true
command: node --inspect=0.0.0.0:9222 index.js
stdin_open: true
redis:
image: grokzen/redis-cluster:5.0.4
environment:
IP: '0.0.0.0'
ports:
- '7000-7005:7000-7005'
package.json: {
"name": "ioredis-repo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"author": "",
"license": "ISC",
"dependencies": {
"ioredis": "^4.9.5"
}
}index.js: const http = require('http');
const Redis = require('ioredis');
const util = require('util');
const cluster = new Redis.Cluster(
[{host: 'redis', port: 7000}],
{
natMap: {
'127.0.0.1:7000': {host: 'redis', port: 7000},
'127.0.0.1:7001': {host: 'redis', port: 7001},
// '127.0.0.1:7002': {host: 'redis', port: 7002},
'127.0.0.1:7003': {host: 'redis', port: 7003},
'127.0.0.1:7004': {host: 'redis', port: 7004},
'127.0.0.1:7005': {host: 'redis', port: 7005},
},
},
).on('error', err => {
console.error('CLUSTER ERROR:', err)
});
http.createServer(async (req, res) => {
const key = 'foo';
cluster
.multi()
.expire(key, 300)
.hgetall(key)
.exec()
.then(results => res.end(JSON.stringify(results)))
.catch(err => {
res.statusCode = 500
res.end(util.format('%o', err))
});
}).listen(3000);http request: snippet from container output: |
|
The number of unhandled rejections corresponds to the |
|
The unhandled rejections are originating here. If I change it to Edit: On a whim, I tried changing that to |
Pipeline#exec() is a little tricky: it has a init process when called first time (indicated by whether Pipeline#nodeifiedPromise is true). Transaction#exec() is similar to that, it has a init process that parse the result from Pipeline#exec before returning to users. However, #nodeifiedPromise is not checked here. Closes: #883
Pipeline#exec() is a little tricky: it has a init process when called first time (indicated by whether Pipeline#nodeifiedPromise is true). Transaction#exec() is similar to that, it has a init process that parse the result from Pipeline#exec before returning to users. However, #nodeifiedPromise is not checked here. Closes: #883
|
Thanks for providing the minimal reproduction, it've been a great help. I created a pr to solve the issue: #884. Still writing tests for it. |
Pipeline#exec() is a little tricky: it has a init process when called first time (indicated by whether Pipeline#nodeifiedPromise is true). Transaction#exec() is similar to that, it has a init process that parse the result from Pipeline#exec before returning to users. However, #nodeifiedPromise is not checked here. Closes: #883
|
🎉 This issue has been resolved in version 4.10.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Hi, I am facing the same issue in ioredis@4.9.0, but I have redis sentinel rather than redis cluster on production. So will upgrading to ioredis to 4.10.2 will solved for me also? |
|
@kunal-til It should only happens when |
|
@luin We are not using the pipeline in code. |
|
@kunal-til Then that should be a separate problem. Please create a new issue for that. |
|
@luin Thanks for the quick response. |
|
This is error we are getting 0|main | 2019-06-28 17:24:13 +05:30: 2019-06-28T11:54:13.768Z ioredis:connection error: Error: connect ETIMEDOUT |
## [4.10.2](redis/ioredis@v4.10.1...v4.10.2) (2019-06-08) ### Bug Fixes * pipeline with transactions causes unhandled warnings ([#884](redis/ioredis#884)) ([bbfd2fc](redis/ioredis@bbfd2fc)), closes [#883](redis/ioredis#883)
I'm intentionally causing a connection error (by omitting a NAT mapping for one cluster node) to verify my application's error handling, but I'm seeing an UnhandledPromiseRejectionWarning:
My code is executing a multi command like this:
I believe this is the relevant debug output preceding the throw:
The promise for
execdoes reject as expected (json taken from my log):{ "type": "Error", "message": "Connection is closed.", "stack": "Error: Connection is closed.\n at close (/home/node/app/node_modules/ioredis/built/redis/event_handler.js:102:25)\n at Socket.<anonymous> (/home/node/app/node_modules/ioredis/built/redis/event_handler.js:73:20)\n at Object.onceWrapper (events.js:288:20)\n at Socket.emit (events.js:200:13)\n at Socket.EventEmitter.emit (domain.js:471:20)\n at TCP.<anonymous> (net.js:586:12)", "previousErrors": [ { "previousErrors": "[Circular]" }, { "previousErrors": "[Circular]" }, { "previousErrors": "[Circular]" } ] }Is there something I can do to catch the rejection?
Possibly related, the
'error'event listener I have attached to the cluster does not trigger when this happens, which also seems unexpected.I was using
4.9.0and tried updating to4.9.5, and have the same experience with both versions.TIA for any guidance!
The text was updated successfully, but these errors were encountered: