Hello John,
Thank you for posting the question.
Regarding the behaviour you encounter, please find below several points to improve in the code snippet above:
- from what I can see your response can be sent as Async, based on what I remember from one of the old cases I had, while sending an Async request or response, the system will not have a good visibility over the execution pipeline and because of this your messages might not be in the proper order and this way your request can silently fail and at the end be killed by the system with a generic error
- looking at the code the HttpRequestMessage in our documentation and also in the RFC documentation mentioned in the .Net Framework documentation, I am unable to clarify if the class can be used sync or Async, but just to confirm, you can try to see if this type of request will provide the correct result using the HttpClient.SendRequestAsync Method
- by default the D365 CE has a timeout at least on the Sandbox level for 2 minutes, depending on the logic behind, my recommendation is not to set it for a longer period of time, but on the other hand this contradicts the Async principle where the Async request will only start to be executed when the system is free
- Looking at the .Net Framework documentation I can see the Send request is only Async:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.sendasync?view=netframework-4.6.1
In order to confirm my findings regarding the Sync and Async request, we will need to take a Fiddler trace, which as you know contains confidential details, therefore if you will like to continue this investigation on Microsoft side, please raise a service request and attach a Fiddler trace to it with the faulty request, or if you have those details, inside the Fiddler trace there is a RequestId or an ActivityId, something similar with x-ms-service-request-id, you can paste the request Id and the date and time of the request in order for us to confirm the details above.
Thank you!
