-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
mvcc: allow clients to assign watcher IDs #9015
Conversation
let us wait for the 3.3 rc release. this should go into 3.4 branch not 3.3 release branch. |
@xiang90 Sounds good. Will merge after 3.3 release branch cut. |
@gyuho let us get this merged into master? |
@xiang90 Yeah let me rebase first and see if test passes. UPDATE: investigating https://semaphoreci.com/coreos/etcd/branches/pull-request-9015/builds/3
This case fails { // watch 1 key, should not be successful
[]kv{},
[]string{"key5", "--rev", "1"},
[]kvExec{},
false,
}, To reproduce ETCDCTL_API=3 ./bin/etcdctl user add root --interactive=false
root
ETCDCTL_API=3 ./bin/etcdctl user grant-role root root
ETCDCTL_API=3 ./bin/etcdctl auth enable
ETCDCTL_API=3 ./bin/etcdctl --user=root:root user add abc --interactive=false
def
ETCDCTL_API=3 ./bin/etcdctl --user=root:root role add test-role
ETCDCTL_API=3 ./bin/etcdctl --user=root:root user grant-role abc test-role
ETCDCTL_API=3 ./bin/etcdctl --user=root:root role grant-permission test-role readwrite foo
ETCDCTL_API=3 ./bin/etcdctl --user=root:root role grant-permission test-role readwrite key key4
ETCDCTL_API=3 ./bin/etcdctl --user=abc:def watch key5 --rev 1
<<COMMENT
expect
Error: watch is canceled by the server
COMMENT |
6a08c6e
to
fcd4c81
Compare
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
This allows for watchers to be created concurrently without needing potentially complex and latency-adding queuing on the client. Signed-off-by: Gyuho Lee <[email protected]>
clientv3/watch.go
Outdated
@@ -367,7 +367,7 @@ func (w *watcher) closeStream(wgs *watchGrpcStream) { | |||
} | |||
|
|||
func (w *watchGrpcStream) addSubstream(resp *pb.WatchResponse, ws *watcherStream) { | |||
if resp.WatchId == -1 { | |||
if resp.Canceled && resp.CancelReason != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xiang90 This PR breaks backward compatibility if we want to returning the original ID from watch create request.
<=
v3.3: canceled watch request response always resp.WatchId == -1
>=
v3.4: canceled watch request response may have watch ID.
So, the way to check cancellation changes. We could keep returning -1 as watch ID on cancellation, but clients won't be able to know which one is canceled...
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
Signed-off-by: Gyuho Lee <[email protected]>
Replaced by #9065. |
Cherry-pick #8662.
Fix #7036.
/cc @connor4312