Don't (a)wait for me about consuldotnet

[highlyunavailable]

I needed them to make this async-all-the-way as far as I could tell. I am not a C# developer by trade and built this to help the dev team interface with Consul when I worked at PlayFab, so I think I missed something when referred to the two articles below when I was trying to make some of the methods sync and some async:

http://blog.stephencleary.com/2012/02/async-and-await.html
https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Given that the code below seems to compile and the tests pass, I'm guessing that I was reading the Task rules wrong and I could return the Task that Execute returns unless I need to transform the result (e.g. KV.Get(string key, QueryOptions q, CancellationToken ct) re-maps an array member to a single object). Good catch, and a wonderful example of cargo cult coding that resulted in a lot of extra work on my part. I'll fix it up. 😄

        public Task<WriteResult<bool>> DeleteCAS(KVPair p)
        {
            return DeleteCAS(p, WriteOptions.Default);
        }

        public Task<WriteResult<bool>> DeleteCAS(KVPair p, WriteOptions q)
        {
            p.Validate();
            var req = _client.Delete<bool>(string.Format("/v1/kv/{0}", p.Key), q);
            req.Params.Add("cas", p.ModifyIndex.ToString());
            return req.Execute();
        }

So, to answer your questions:

What do I miss? Is there a meaning behind the awaits? (Just before returning the tasks).

Good catch, that's a bug and I'll fix it.

This tool seem cool and I want to help, do you have any thoughts about the future?

There really isn't a future to it other than "keep it up to date with the Consul Go API." I am explicitly keeping it very low-level - my view is if you want to build a tool that uses it, great, but I don't see this project as a way to add a ton of additional functionality to this API (e.g. remote execution via consul without shelling out to consul exec was something I attempted and abandoned as out of scope.)

I'd say there are two different things that would help:

1. Go over the codebase in code-review fashion and file bugs on stuff you find that's weird, non-idiomatic, inefficient, or otherwise wrong. Optionally, make PRs to fix them. This is probably the most helpful and easiest thing to do.
2. There are quite a few commits to the Consul Go API history that I haven't had time to add - I think everything after and including 95c708f65e69562b1aa22e78d130a532c7f3f85c (Adds Docker checks support to client API.) is missing from the C# API, and if you wanted add functionality like the lock retry capability and porting the related tests, that would be great, though you also have to know Go and be able to translate the two languages' idioms in your head.

[TKul6]

Great I'll look up the Consul Go history. and when I have a little bit more time I'll dive into the code and see if there good stuff that can be great! :)