Fix Easy Racer .NET tests (fix async/await)

[HofmeisterAn]

Hi 👋, I came across this project and noticed some issues/flaws in the .NET implementation. After investigating, I propose the following changes:

1. The usage of async void is generally not recommended (except for events). I couldn't find a reason why the tests should use this method signature; using async Task is the preferred approach and is recommended.
2. Synchronously waiting on an asynchronous operation (sync over async) is also not recommended and should be avoided. It blocks (wastes) one thread, which can lead to thread starvation and deadlocks.
3. It is recommended to let Testcontainers resolve the actual Hostname. Depending on the container runtime and environment, the host can differ. Using the static value localhost can cause further issues. There is a bug or an issue in Docker Desktop where the IPv4/IPv6 binding does not get the same port assigned. Depending on how the operating system resolves localhost, it is necessary to resolve to the correct randomly assigned host port (find further information here).
4. Scenario 10 does not consider the culture when converting the double CPU usage to a string. This breaks the HTTP request because, depending on the user's OS and settings, 0.95d.ToString() will be 0,95 instead of 0.95.

Before the changes, I was not able to run the tests. With the mentioned changes, the tests now run fine. However, TestScenario3 is still sometimes flaky. Unfortunately, I haven't had the time to take a closer look at it.

[delormej]

@HofmeisterAn thanks for the feedback! I'll review this in depth and make the appropriate fixes, including digging into Scenario 3 again. Thanks again for looking!

[jamesward]

Thank you @HofmeisterAn for the improvements!

[HofmeisterAn]

👍 If you need help with the changes or have questions, feel free to reach out to me. I am happy help. Perhaps I will find some time to look into TestScenario3 too.

[delormej]

Thanks for catching the hardcoded localhost hostname in the url here. Any reason why we should just the URL and port on the Library itself instead of passing it to each method call? I was following @jamesward pattern for the others, but seems like this should be captured at the library level?

[HofmeisterAn]

Yes, I was considering something similar, but I did not want to introduce unnecessary changes. Setting the BaseAddress of HttpClient as follows:

using var httpClient = new HttpClient();
// TODO: Set it to the correct container address.
httpClient.BaseAddress = new Uri("http://localhost:8080");

// Calls http://localhost:8080/1
_ = await httpClient.GetAsync("1");

// Calls http://localhost:8080/2
_ = await httpClient.GetAsync("2");

makes the GetUrl(string, ushort) method obsolete.

[delormej]

The instructions (https://github.com/jamesward/easyracer) are looking for this to run every 1 second.

Part 2) In parallel to Part 1, every 1 second, make a request with the current process load (0 to 1)

[HofmeisterAn]

Good catch; I think this was by accident. I will change it 👍.

[jjdelorme]

Quick note on why Scenario 3 is breaking when running it multiple times... It turns out there is an InnerException buried in the stack which is System.Net.Sockets.SocketException (104): Connection reset by peer. Looks like it's some kind of denial of service detection; https://stackoverflow.com/questions/57813659/why-is-there-a-threshold-of-concurrent-http-requests-i-can-make-using-httpclien

I've fixed this by implementing a simple RetryHandler, but I'll make it a little more robust with exponential back-off.