sryanyuan commented on PR #3378: URL: https://github.com/apache/kvrocks/pull/3378#issuecomment-3995988490
> > I've reviewed the CLIENT PAUSE/UNPAUSE implementation and noticed a couple of behavioral differences compared to Redis that I wanted to flag: > > Blocking Scope (ALL mode): > > In Redis, CLIENT PAUSE timeout ALL blocks all commands (including CLIENT PAUSE/UNPAUSE itself). In our current implementation, these commands remain unblocked. > > Overwriting Behavior (WRITE mode): > > When re-invoking CLIENT PAUSE timeout WRITE during an active write-block: > > Redis: Only allows overwriting if the new timeout is longer than the remaining time, or if using ALL (which overrides WRITE). Current Implementation: New WRITE pauses fully overwrite existing ones (timeout + config), regardless of duration/type. > > Could we confirm if these differences align with the intended behavior for Kvrocks? > > First question: According to the official documentation ([PAUSE](https://redis.io/docs/latest/commands/client-pause/) & [UNPAUSE](https://redis.io/docs/latest/commands/client-unpause/)),CLIENT PAUSE should not block itself or CLIENT UNPAUSE, the current implementation in the redis source code appears to deviate from this rule. This inconsistency is concerning because it introduces a significant operational risk: > > If CLIENT PAUSE ALL inadvertently blocks the very commands intended to manage it, an accidental long timeout could leave the cluster unrecoverable until the timer expires. From a system reliability perspective, this design is fundamentally unsafe.Therefore, an "emergency exit" (or backdoor) was specifically implemented for UNPAUSE to prevent such scenarios. Understood. The key point was primarily to discuss behavioral differences between implementations. Based on source code and actual behavior: WRITE mode does not block CLIENT UNPAUSE ALL mode blocks CLIENT UNPAUSE Assuming this difference is intentional and expected, it’s perfectly acceptable. Appreciate the clarification! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
