Compressing a stream asynchronously, and returning a byte[]

Question

Assuming I have to leave the contract intact (take byte[] and return byte[]), what's the correct way to structure this asynchronous method?

Will this deadlock running in ASP.NET in a web server thread?

public async Task<byte[]> CompressAsync(byte[] buffer)
{
 using (var outStream = new MemoryStream())
 {
 using (var tinyStream = new GZipStream(outStream, CompressionMode.Compress))
 using (var stream = new MemoryStream(buffer))
 {
 await stream.CopyToAsync(tinyStream);
 }
 return outStream.ToArray();
 } 
}

• Nikita B: I think your last question is off-topic. We review working code here, while you are kind of asking us if your code works.
• konijn: @NikitaBrizhak Disagreed, it is very hard to test for deadlocks. All asynchronous code can possibly go wrong, that does not mean all asynchronous code is not working.
• Nikita B: @konijn, if asynchronous code can possibly "go wrong", than it does not work.
• Jim: The code does work. I passes several unit and integration tests. The trick is that unless async and await are used throughout the pipeline, ASP.NET can deadlock. Most library code needs to use ConfigureAwait in order to ensure it works when an ASP.NET thread waits. It's mentioned in the answer below. I agree the statement that all asynchronous code can go wrong is basically solipsist.

Answer 1

I don't see any reason for the inner stream. Instead, you can just WriteAsync() the whole buffer directly into the (confusingly named) tinyStream.

---

Your code won't deadlock if used properly (i.e. asynchronously), but it will deadlock if someone synchronously waits for it (e.g. byte[] resultBuffer = CompressAsync(inputBuffer).Result;). To make sure this doesn't happen, add .ConfigureAwait(false) after every await.

You should do this for all your "library" code, that is code that doesn't need to run in the ASP.NET request context/GUI thread.

---

This method doesn't use any instance state. Why isn't it static?

• Jim: I almost never use static methods for anything. This method is part of a larger class that implements an interface to ensure it can be doubled in unit and integration tests. I don't really have static methods anymore as everything needs tests.
• svick: @Jim You can test static methods just as easily as instance methods. Or are you talking about the difficulty of mocking them?
• Jim: I am talking about mocking, I mock out the compression and encryption in unit tests.