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

We got the error of All keys in the pipeline should belong to the same slots allocation group when enableAutoPipelining set true #1248

Closed
yunnysunny opened this issue Dec 5, 2020 · 3 comments

Comments

@yunnysunny
Copy link

yunnysunny commented Dec 5, 2020

The error stack is below:

    at Pipeline.exec (/myapp/node_modules/ioredis/built/pipeline.js:250:29)
    at executeAutoPipeline (/myapp/node_modules/ioredis/built/autoPipelining.js:41:14)
    at /myapp/node_modules/ioredis/built/autoPipelining.js:59:13
    at tryCatcher (/myapp/node_modules/standard-as-callback/built/utils.js:11:23)
    at /myapp/node_modules/standard-as-callback/built/index.js:19:49
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

When update our version to 4.19.2 and set enableAutoPipelining true, the error come up. It make us annoying. And then we disabled the enableAutoPipelining, the error dismissing.

We also met with an uncaught exception that make the process exited:

TypeError: Cannot read property 'Symbol(callbacks)' of undefined
    at Immediate.executeAutoPipeline (/myapp/node_modules/ioredis/built/autoPipelining.js:39:31)
    at processImmediate (internal/timers.js:441:21)

It increased our determination to disable enableAutoPipelining.

@simoneb
Copy link

simoneb commented Feb 11, 2021

Can you please provide a reproduction for this issue? A code example would work. Thanks

@Paul-Isache
Copy link

Checked on latest version of ioredis ,4.22.0 down to 4.19.0, with 2 master and 3 slaves, and I am not able to reproduce it.

kemmerer pushed a commit to kemmerer/ioredis that referenced this issue Apr 13, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

This may fix redis#1264 and redis#1248.
TysonAndre pushed a commit to TysonAndre/ioredis that referenced this issue Jul 27, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files

This may fix redis#1264 and redis#1248.
TysonAndre pushed a commit to TysonAndre/ioredis that referenced this issue Jul 27, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 28, 2021
Previously the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Similarly, `args[0]` can be a (possibly empty) array which the Command
constructor would flatten. Properly compute the first flattened key when
autopipelining for a Redis.Cluster instance.

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 31, 2021
Previously, the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Similarly, `args[0]` can be a (possibly empty) array which the Command
constructor would flatten. Properly compute the first flattened key when
autopipelining for a Redis.Cluster instance.

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.

Fixes redis#1392
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Jul 31, 2021
Previously, the building of pipelines ignored the key prefix.
It was possible that two keys, foo and bar, might be set into
the same pipeline. However, after being prefixed by a configured
"keyPrefix" value, they may no longer belong to the same
pipeline.

This led to the error:
"All keys in the pipeline should belong to the same slots
allocation group"

Similarly, `args[0]` can be a (possibly empty) array which the Command
constructor would flatten. Properly compute the first flattened key when
autopipelining for a Redis.Cluster instance.

Amended version of https://github.com/luin/ioredis/pull/1335/files - see comments on that PR

This may fix redis#1264 and redis#1248.

Fixes redis#1392
@luin luin closed this as completed in d7477aa Aug 1, 2021
ioredis-robot pushed a commit that referenced this issue Aug 1, 2021
## [4.27.7](v4.27.6...v4.27.7) (2021-08-01)

### Bug Fixes

* **cluster:** fix autopipeline with keyPrefix or arg array ([#1391](#1391)) ([d7477aa](d7477aa)), closes [#1264](#1264) [#1248](#1248) [#1392](#1392)
@ioredis-robot
Copy link
Collaborator

🎉 This issue has been resolved in version 4.27.7 🎉

The release is available on:

Your semantic-release bot 📦🚀

TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Aug 27, 2021
Seen in an uncaughtException handler.

```
err_type=uncaughtException, exiting cause=TypeError: Cannot read property 'Symbol(callbacks)' of undefined
    at Immediate.executeAutoPipeline (.../node_modules/ioredis/built/autoPipelining.js:34:31)
    at Shim.applySegment (.../node_modules/newrelic/lib/shim/shim.js:1430:20)
    at Immediate.wrapper (.../node_modules/newrelic/lib/shim/shim.js:2097:17)
    at processImmediate (internal/timers.js:463:21)
```

A similar error was among the errors reported in
redis#1248

I suspect the async nature of the delete call may cause it to be
deleted.
TysonAndre added a commit to TysonAndre/ioredis that referenced this issue Aug 27, 2021
Seen in an uncaughtException handler.

```
err_type=uncaughtException, exiting cause=TypeError: Cannot read property 'Symbol(callbacks)' of undefined
    at Immediate.executeAutoPipeline (.../node_modules/ioredis/built/autoPipelining.js:34:31)
    at Shim.applySegment (.../node_modules/newrelic/lib/shim/shim.js:1430:20)
    at Immediate.wrapper (.../node_modules/newrelic/lib/shim/shim.js:2097:17)
    at processImmediate (internal/timers.js:463:21)
```

A similar error was among the errors reported in
redis#1248

I suspect the process.exec might call the callback synchronously in the
same tick in some cases, immediately deleting the autopipeline from
running pipelines?
luin pushed a commit that referenced this issue Aug 30, 2021
Seen in an uncaughtException handler.

```
err_type=uncaughtException, exiting cause=TypeError: Cannot read property 'Symbol(callbacks)' of undefined
    at Immediate.executeAutoPipeline (.../node_modules/ioredis/built/autoPipelining.js:34:31)
    at Shim.applySegment (.../node_modules/newrelic/lib/shim/shim.js:1430:20)
    at Immediate.wrapper (.../node_modules/newrelic/lib/shim/shim.js:2097:17)
    at processImmediate (internal/timers.js:463:21)
```

A similar error was among the errors reported in
#1248

I suspect the process.exec might call the callback synchronously in the
same tick in some cases, immediately deleting the autopipeline from
running pipelines?
Bastian added a commit to Bastian/bstats-backend that referenced this issue Sep 4, 2022
Fixes issue with auto pipelining.

See redis/ioredis#1248
janus-dev87 added a commit to janus-dev87/ioredis-work that referenced this issue Mar 1, 2024
## [4.27.7](redis/ioredis@v4.27.6...v4.27.7) (2021-08-01)

### Bug Fixes

* **cluster:** fix autopipeline with keyPrefix or arg array ([#1391](redis/ioredis#1391)) ([d7477aa](redis/ioredis@d7477aa)), closes [#1264](redis/ioredis#1264) [#1248](redis/ioredis#1248) [#1392](redis/ioredis#1392)
janus-dev87 added a commit to janus-dev87/ioredis-work that referenced this issue Mar 1, 2024
Seen in an uncaughtException handler.

```
err_type=uncaughtException, exiting cause=TypeError: Cannot read property 'Symbol(callbacks)' of undefined
    at Immediate.executeAutoPipeline (.../node_modules/ioredis/built/autoPipelining.js:34:31)
    at Shim.applySegment (.../node_modules/newrelic/lib/shim/shim.js:1430:20)
    at Immediate.wrapper (.../node_modules/newrelic/lib/shim/shim.js:2097:17)
    at processImmediate (internal/timers.js:463:21)
```

A similar error was among the errors reported in
redis/ioredis#1248

I suspect the process.exec might call the callback synchronously in the
same tick in some cases, immediately deleting the autopipeline from
running pipelines?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants