The code generated by NSwag allows the consumer to pass a CancellationToken, which it uses on the call to HttpClient.SendAsync, but it doesn't use on the downstream call to response.Content.ReadAsStringAsync.
This is a potential issue, because the NSwag-generated call to SendAsync uses HttpCompletionOption.ResponseHeadersRead, meaning the SendAsync call will return as soon as the headers are read (it will not wait for the full response body to be read, that will happen on the subsequent call to response.Content.ReadAsStringAsync).
The Microsoft Documentation suggests the HttpCompletionOption.ResponseHeadersRead option means the following call to ReadAsStringAsync could block, because the CancellationToken (as well as the default timeout) only applies to the SendAsync call.
I am seeing this behavior at my end. Http log statements before and after the SendAsync call are appearing, but nothing afterward. My best guess is the host service becomes unresponsive during the ReadAsStringAsync call, causing an infinite block.
How can we get NSwag to use the CancellationToken on the ReadAsStringAsync call as the Microsoft documentation suggests? Are custom NSwag templates the only way, or is there a better option?
I made a change to NSwag to apply the cancellationToken to the ReadAsStringAsync and ReadAsStreamAsync calls when the framework is .NET 5 or higher. My change should be available in the 14.5 version of NSwag, or the nightly build of master if you need it sooner.