Closed davissp14 closed 5 years ago
This is fixed by https://github.com/davissp14/etcdv3-ruby/pull/115
@mgates That fixes the specs, but I'm actually a bit more interested in the underlining regression within gRPC's deadline functionality.
I opened an issue with them today:
https://github.com/grpc/grpc/issues/15314
If this is just an edge case with 0 based deadlines, then i'd be happy to merge that guy.
Yeah, our theory was that when another connection was already open, the request got to etcd fast enough to be within the deadline window, and when it wasn't open, it look long enough to open the connection that the deadline had passed. That's just gut though, we didn't run it to ground.
Seems to be fixed by using GRPC::Core::TimeConsts.from_relative_time
instead for Time.now.to_f + X
. See #122 ( for example: https://github.com/davissp14/etcdv3-ruby/pull/122/files#diff-7e89c206323ba5960be7eee8448c0a35L124 )
This can be closed imho as it should be fixed now.
Timeout related specs appear to break due to gRPC changes in v1.8.0.
Branch to reproduce: https://github.com/davissp14/etcdv3-ruby/tree/grpc-update
Travis Build reference: https://travis-ci.org/davissp14/etcdv3-ruby/jobs/374700857
cc:// @mgates