CLIENT UNBLOCK should't be able to unpause paused clients by enjoy-binbin · Pull Request #2117 · valkey-io/valkey

enjoy-binbin · 2025-05-22T04:09:59Z

When a client is blocked by something like CLIENT PAUSE, we should not
allow CLIENT UNBLOCK timeout to unblock it, since some blocking types
does not has the timeout callback, it will trigger a panic in the core,
people should use CLIENT UNPAUSE to unblock it.

Also using CLIENT UNBLOCK error is not right, it will return a UNBLOCKED
error to the command, people don't expect a SET command to get an error.

So in this commit, in these cases, we will return 0 to CLIENT UNBLOCK
to indicate the unblock is fail. The reason is that we assume that if
a command doesn't expect to be timedout, it also doesn't expect to be
unblocked by CLIENT UNBLOCK.

The old behavior of the following command will trigger panic in timeout
and get UNBLOCKED error in error. Under the new behavior, client unblock
will get the result of 0.

client 1> client pause 100000 write
client 2> set x x

client 1> client unblock 2 timeout
or
client 1> client unblock 2 error

Potentially breaking change, previously allowed CLIENT UNBLOCK error.
Fixes #2111.

…meout callback When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]>

codecov · 2025-05-22T04:24:51Z

Codecov Report

Attention: Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 71.21%. Comparing base (36b51c9) to head (4db45f8).
Report is 38 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/blocked.c	85.71%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2117      +/-   ##
============================================
+ Coverage     71.19%   71.21%   +0.02%     
============================================
  Files           122      122              
  Lines         66046    66053       +7     
============================================
+ Hits          47020    47039      +19     
+ Misses        19026    19014      -12

Files with missing lines	Coverage Δ
src/networking.c	`87.29% <100.00%> (+0.10%)`	⬆️
src/server.h	`100.00% <ø> (ø)`
src/blocked.c	`91.31% <85.71%> (-0.12%)`	⬇️

... and 13 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

gmbnomis

Although this could be regarded as a breaking change (of undocumented behavior), I think the behavior proposed by this PR is the most consistent option.

tests/unit/pause.tcl

Signed-off-by: Binbin <[email protected]>

ranshid

Overall LGTM. small comment which I myself am not sure of.

src/blocked.c

zuiderkwast

LGTM.

Conceptually, for users, blocked clients and paused clients are two separate concepts. They can't be mixed.

We just use the same mechanism internally.

zuiderkwast · 2025-05-26T11:19:35Z

Let's backport it to all versions, ok?

Or only backport the client unblock timeout case where it could crash?

ranshid · 2025-05-26T12:31:14Z

Let's backport it to all versions, ok?

Or only backport the client unblock timeout case where it could crash?

I think cherry picking the exact code would be easier and not a problem. I am not sure why the error is ever used (as I am also not sure when is this API ever used in realtime scenarios and not testing)

gmbnomis · 2025-05-26T15:30:23Z

I wonder if the change is more severe than it appears at first glance. One could implement the "monitor a changing set of keys" idea from the documentation of CLIENT UNBLOCK as follows:

Loop forever:

BLPOP <current set of observed keys> 0
If not timed out: work on result

And in parallel:

Trigger when set of keys changes:

Update current set of observed keys
CLIENT UNBLOCK <client id>

Key property today: Client unblocking works even during CLIENT PAUSE, ensuring the key set gets updated on next iteration. (Note that there is no need to even look at the reply of CLIENT UNBLOCK)

The proposed change in this PR creates ambiguity in the CLIENT UNBLOCK response:

"0" reply could now mean either:

Client wasn't blocked
Client couldn't be unblocked due to pause (new meaning)

This will break the code above if the trigger occurs when BLPOP is blocking due to CLIENT PAUSE: The BLPOP will continue to wait using the outdated set of keys even if the clients will be unpaused later.

I still think that unblocking the client is wrong (as said by @zuiderkwast CLIENT PAUSE and blocking commands are two different concepts). But maybe CLIENT UNBLOCK should return an error if the command can't be unblocked due to a CLIENT PAUSE? (or should CLIENT UNBLOCK block?)

zuiderkwast · 2025-05-26T16:10:51Z

@gmbnomis Good point. It seems that we should unblock the client if it's blocked and paused at the same time. I.e. it should be possible to unblock a BLPOP even during client pause write. Makes sense?

gmbnomis · 2025-05-26T19:33:14Z

It seems that we should unblock the client if it's blocked and paused at the same time. I.e. it should be possible to unblock a BLPOP even during client pause write.

That's an interesting perspective. Basically, because pausing clients and blocking commands are different concepts from a user's perspective, we could argue that the user does not need to be concerned with the underlying reason why a blocking command is blocked.

So yes, it makes sense that CLIENT UNBLOCK will just unblock it. And, as this neither reads or writes, this does no harm even if done during a read-write pause. (but I suppose it will be a pain to implement this behavior)

OTOH, my scenario from above turns out to be not fully correct: Today, the server panics when a CLIENT UNBLOCK TIMEOUT is issued for a client that is paused (even if it is a blocking command). Only a CLIENT UNBLOCK ERROR works. So, I wonder if anybody is actually using this pattern...

zuiderkwast · 2025-05-27T13:47:57Z

Today, the server panics when a CLIENT UNBLOCK TIMEOUT is issued for a client that is paused (even if it is a blocking command).

Yes, I can confirm this. This is an even worse bug IMO. It means the server can crash when you try to CLIENT UNBLOCK a client that is blocking on BLPOP. The user may not know that CLIENT PAUSE is in action, for example during a failover or something like that.

The fix prevents the crash, but unfortunately it prevents unblocking BLPOP while clients are paused, but this depends on which was first: block or pause.

If a command was blocked before paused, it is possible to unblock it using CLIENT UNBLOCK.
If clients were paused before a blocking command was called and blocked, it's not possible to unblock it using CLIENT UNBLOCK.

gmbnomis · 2025-06-02T18:30:10Z

The fix prevents the crash, but unfortunately it prevents unblocking BLPOP while clients are paused, but this depends on which was first: block or pause.
* If a command was blocked before paused, it is possible to unblock it using CLIENT UNBLOCK.

* If clients were paused before a blocking command was called and blocked, it's not possible to unblock it using CLIENT UNBLOCK.

@zuiderkwast Yes, this is true. I think that none of the alternatives to this behavior is optimal:

Unblock clients regardless of pause/block state
- Pros: Consistent unblocking behavior.
- Cons: When clients are paused early in command processing, we lack the necessary context (command type, expected reply) to generate a proper timeout response, especially for module commands. This would likely require a new module API to communicate this information.
Return an error when paused
- Pros: Simple to implement.
- Cons: Unexpected for clients, as they may not anticipate this error.
Postpone CLIENT UNBLOCK of a paused command until the pause expires/is lifted
- Pros: From the client’s perspective, this is similar to option 1 but with some delay—in certain cases (like WAIT), this may be the most logical behavior.
- Cons: This introduces a (new?) edge case where one command is deferred by another. We’d need to ensure that commands are unblocked and executed in the correct order, but since blocked commands are already managed in a linked list, this might be feasible.

Overall, option 3 makes most sense to me.

zuiderkwast · 2025-06-02T19:25:54Z

All options have pros and cons. 🤔 They also require more work, and these cases are very unusual. Maybe there is no use case for these combinations?

IMO we can merge this PR. It is simple and it prevents the crash, which is the most important problem to fix. OK?

enjoy-binbin · 2025-06-03T02:45:07Z

@gmbnomis Thank you for your summary comment
@valkey-io/core-team Please also take a look at the comments above and vote.

ranshid · 2025-06-03T09:21:46Z

The fix prevents the crash, but unfortunately it prevents unblocking BLPOP while clients are paused, but this depends on which was first: block or pause.
* If a command was blocked before paused, it is possible to unblock it using CLIENT UNBLOCK.

* If clients were paused before a blocking command was called and blocked, it's not possible to unblock it using CLIENT UNBLOCK.
@zuiderkwast Yes, this is true. I think that none of the alternatives to this behavior is optimal:

Unblock clients regardless of pause/block state

Pros: Consistent unblocking behavior.

Cons: When clients are paused early in command processing, we lack the necessary context (command type, expected reply) to generate a proper timeout response, especially for module commands. This would likely require a new module API to communicate this information.

Return an error when paused

Pros: Simple to implement.

Cons: Unexpected for clients, as they may not anticipate this error.

Postpone CLIENT UNBLOCK of a paused command until the pause expires/is lifted

Pros: From the client’s perspective, this is similar to option 1 but with some delay—in certain cases (like WAIT), this may be the most logical behavior.

Cons: This introduces a (new?) edge case where one command is deferred by another. We’d need to ensure that commands are unblocked and executed in the correct order, but since blocked commands are already managed in a linked list, this might be feasible.

Overall, option 3 makes most sense to me.

I think that (as I think you also state) the ambiguity was always there. when we pause clients some commands with timeout are not fulfilling the timeout guarantee since it is just too hard to do so. For example we cannot timeout commands which are just sitting in the incoming socket stream as we did not yet parse them.
I think this PR is fine in solving the immediate problem. I would also think that extending CLIENT PAUSE with an extra optional argument (client-id) would be a better choice to extend the API to be more clear and allow unblocking a specific paused client

zuiderkwast · 2025-06-07T02:19:30Z

Let's merge it so it can be included in

8.1.2 release #2173

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]>

When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes #2111. Signed-off-by: Binbin <[email protected]>

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> Signed-off-by: chzhoo <[email protected]>

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> (cherry picked from commit 3bc40be)

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> Signed-off-by: shanwan1 <[email protected]>

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> Signed-off-by: Ran Shidlansik <[email protected]>

When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes #2111. Signed-off-by: Binbin <[email protected]> Signed-off-by: Ran Shidlansik <[email protected]>

This PR is based on valkey-io/valkey#2117 When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` --------- Signed-off-by: Binbin <[email protected]> Co-authored-by: Binbin <[email protected]>

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> (cherry picked from commit 3bc40be)

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> (cherry picked from commit 3bc40be) Signed-off-by: Viktor Söderqvist <[email protected]>

When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes #2111. Signed-off-by: Binbin <[email protected]> (cherry picked from commit 3bc40be) Signed-off-by: Viktor Söderqvist <[email protected]>

…2117) When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` Potentially breaking change, previously allowed `CLIENT UNBLOCK error`. Fixes valkey-io#2111. Signed-off-by: Binbin <[email protected]> (cherry picked from commit 3bc40be) Signed-off-by: Viktor Söderqvist <[email protected]>

This PR is based on valkey-io/valkey#2117 When a client is blocked by something like `CLIENT PAUSE`, we should not allow `CLIENT UNBLOCK timeout` to unblock it, since some blocking types does not has the timeout callback, it will trigger a panic in the core, people should use `CLIENT UNPAUSE` to unblock it. Also using `CLIENT UNBLOCK error` is not right, it will return a UNBLOCKED error to the command, people don't expect a `SET` command to get an error. So in this commit, in these cases, we will return 0 to `CLIENT UNBLOCK` to indicate the unblock is fail. The reason is that we assume that if a command doesn't expect to be timedout, it also doesn't expect to be unblocked by `CLIENT UNBLOCK`. The old behavior of the following command will trigger panic in timeout and get UNBLOCKED error in error. Under the new behavior, client unblock will get the result of 0. ``` client 1> client pause 100000 write client 2> set x x client 1> client unblock 2 timeout or client 1> client unblock 2 error ``` --------- Signed-off-by: Binbin <[email protected]> Co-authored-by: Binbin <[email protected]>

gmbnomis reviewed May 22, 2025

View reviewed changes

tests/unit/pause.tcl Show resolved Hide resolved

tests/unit/pause.tcl Show resolved Hide resolved

enjoy-binbin added 2 commits May 23, 2025 11:04

Update the test

cdcd654

Signed-off-by: Binbin <[email protected]>

Merge remote-tracking branch 'upstream/unstable' into fix_block

4db45f8

Signed-off-by: Binbin <[email protected]>

ranshid approved these changes May 26, 2025

View reviewed changes

src/blocked.c Show resolved Hide resolved

ranshid added release-notes This issue should get a line item in the release notes breaking-change Indicates a possible backwards incompatible change labels May 26, 2025

zuiderkwast approved these changes May 26, 2025

View reviewed changes

zuiderkwast changed the title ~~CLIENT UNBLOCK should't be able to unblock client that doesn't has timeout callback~~ CLIENT UNBLOCK should't be able to unpause paused clients May 26, 2025

zuiderkwast added this to Valkey 8.1, Valkey 8.0 and Valkey 7.2 May 26, 2025

2asasa1 mentioned this pull request May 27, 2025

Introduce CLUSTERLOG command support #2029

Open

soloestoy approved these changes Jun 3, 2025

View reviewed changes

madolson approved these changes Jun 9, 2025

View reviewed changes

enjoy-binbin requested a review from hpatro June 10, 2025 02:28

enjoy-binbin merged commit 3bc40be into valkey-io:unstable Jun 10, 2025
51 checks passed

github-project-automation bot moved this to To be backported in Valkey 8.0 Jun 10, 2025

github-project-automation bot moved this to To be backported in Valkey 8.1 Jun 10, 2025

github-project-automation bot moved this to To be backported in Valkey 7.2 Jun 10, 2025

enjoy-binbin deleted the fix_block branch June 10, 2025 02:29

enjoy-binbin mentioned this pull request Jun 10, 2025

8.1.2 release #2173

Merged

hpatro moved this from To be backported to 8.1.2 in Valkey 8.1 Jun 11, 2025

vitarb mentioned this pull request Jun 13, 2025

Fixes for Valkey 8.0.5 #2210

Merged

ranshid moved this from To be backported to In Progress in Valkey 7.2 Jun 18, 2025

sundb mentioned this pull request Jul 3, 2025

CLIENT UNBLOCK should't be able to unpause paused clients redis/redis#14164

Merged

zuiderkwast moved this from To be backported to 8.0.5 in Valkey 8.0 Aug 18, 2025

rainsupreme moved this from In Progress to 7.2.10 in Valkey 7.2 Sep 29, 2025

Conversation

enjoy-binbin commented May 22, 2025

Uh oh!

codecov bot commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

gmbnomis left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ranshid left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zuiderkwast left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zuiderkwast commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ranshid commented May 26, 2025

Uh oh!

gmbnomis commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zuiderkwast commented May 26, 2025

Uh oh!

gmbnomis commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zuiderkwast commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gmbnomis commented Jun 2, 2025

Uh oh!

zuiderkwast commented Jun 2, 2025

Uh oh!

enjoy-binbin commented Jun 3, 2025

Uh oh!

ranshid commented Jun 3, 2025

Uh oh!

zuiderkwast commented Jun 7, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

codecov bot commented May 22, 2025 •

edited

Loading

gmbnomis left a comment •

edited

Loading

zuiderkwast left a comment •

edited

Loading

zuiderkwast commented May 26, 2025 •

edited

Loading

gmbnomis commented May 26, 2025 •

edited

Loading

gmbnomis commented May 26, 2025 •

edited

Loading

zuiderkwast commented May 27, 2025 •

edited

Loading