Guilherme Balena Versiani

I confirm that the above is indeed a problem with the implementation. The etcd v3 API states that: > A watch stream is bi-directional; the client writes to the stream...

Attempted to address the problem in https://github.com/zhongwencool/eetcd/pull/50. > It can be a reasonable design choice for a client library to not perform connection recovery Yes, it can, but in this...

It's easy to reproduce. The steps were described at the top of this issue. In order to interrupt the connectivity of the client running eetcd just turn off the network...

Gentle bump @michaelklishin @zhongwencool.

I was having exactly the same problem and it gone away after migrating to `asyncomplete.vim`. Other problems came, though, as now I don't get completion for the current file, like,...

Indicating that the process should have a lifetime that surpasses the natural logic of a regular `GenServer` means that we're probably willing to adopt a `restart: :permanent` policy, just like...

This PR also solves https://github.com/bitwalker/swarm/issues/11 as the indicated solution of using `Swarm.Tracker` not always work (needs synchronization when terminating the app or there is no handoff at all).

I just added a PR adding a `restart` parameter to `Swarm.register_name` to the caller can decide what to do when the pid terminates gracefully (or not), [here](https://github.com/bitwalker/swarm/pull/139). The parameter name...

I was able to reproduce the problem as follows: ``` > {lclock, rclock} = Clock.seed() |> Clock.fork() > {lclock1, rclock1} = Clock.fork(lclock) > Clock.join(lclock, rclock1) ** (FunctionClauseError) no function clause...

Hey @derekkraan, Sorry for adding more changes to the PR. I would have created a separated branch instead of using `master`. But the two problems I am attempting to solve...