Avoid panic when using dedicated client after being recycled, return an error instead #593
Conversation
| @@ -392,4 +392,3 @@ func dial(dst string, opt *ClientOption) (conn net.Conn, err error) { | |||
| } | |||
|
|
|||
| const redisErrMsgCommandNotAllow = "command is not allowed" | |||
| const dedicatedClientUsedAfterReleased = "DedicatedClient should not be used after recycled" | |||
There was a problem hiding this comment.
Hi @FZambia,
Many thanks! I originally planned to take care of this issue over the coming weekend.
The PR looks great and works great. We should indeed replace all panics caused by the c.check(). ErrClosing can work, however, I think to avoid further confusion we had better use a new error and keep the original message. For example: ErrDedicatedClientRecycled = errors.New("dedicated client should not be used after recycled")
There was a problem hiding this comment.
Yep, will update PR - that was my first thought too but then I found ErrClosing and decided to re-use existing error. BTW, how about changing should -> must in error message?
There was a problem hiding this comment.
Sounds good to me too. Just curious why you think a must is better.
There was a problem hiding this comment.
I was thinking in terms of https://www.ietf.org/rfc/rfc2119.txt. But thinking more, given my personal use case, it seems should can fit here too. Let's go with should.
There was a problem hiding this comment.
@rueian , so I started implementing an error as you suggested, and realized that I don't clearly see a semantic difference between ErrClosing and ErrDedicatedClientRecycled. Why do you think a separate error is better in this case to avoid the confusion and how it differs from ErrClosing?
From library user's perspective I think ErrClosing clearly states that the client was used after closing, while ErrDedicatedClientRecycled exposes implementation details to the user, and eventually it may be more confusing to read. WDYT?
Probably ErrClosed instead of ErrDedicatedClientRecycled could be much more clear here if ErrClosing does not semantically fit.
There was a problem hiding this comment.
The message of ErrClosing is rueidis client is closing or unable to connect redis. I think it conveys too much misleading information in this case.
For example, when a user hits the c.check() and sees the message, he/she may wonder:
- I didn't call
Close()on my client. Who closed my client? But it was actually he/she called thecancel(). unable to connect redis? Was there a networking issue? But it was actually he/she called thecancel().
I think this is how ErrDedicatedClientRecycled differs from ErrClosing. It serves the c.check() only.
There was a problem hiding this comment.
Thx for the answer. It's more clear to me now – so it's an error specific to the state of dedicated clients only. I just pushed the updated version, please check it out.
FZambia
changed the title
Relates #586
This PR contains changes to avoid panicking with
DedicatedClient should not be used after recycled, and return an error (specifically,ErrClosing) instead.Please take a look. The thing I personally not sure whether it's semantically correct to use
ErrClosingin these places. At first glance seems logical, but probably will require adjustments. Also, #586 mentions only panic forDocall, but I guess it should be extrapolated to all methods to fully eliminate panic.