short answer: because it's asynchronous.
when dealing with synchronous requests, the response is usually easy to get, because it's just there at the end of the calling method.
dealing with asynchronous requests is way more complicated! because you usually don't have access to the response code at the point in time when the request is sent - obviously, because it's asynchronous. so for all the asynchronous technologies we have to find 2 places, one where the request is sent and one where the response is read and the response code is already available. this handling of asynchronous technologies is implemented by us step-by-step, but it looks like we don't have it available for that kind of async calls (yet).
Thank you very much for the explanation.
Is this step-by-step implementation something we can do ourselves at the customer? (i.e. with maybe a custom sensor) or should it just be raised with dev and wait for it to be included in one of the fixpacks or releases?
well, theoretically, if you knew exactly what to instrument and capture you could potentially get to the response code via a custom sensor ... but you would not have the usual benefits like error detection and so on. also it might be hard to impossible to figure which request that response code belongs to.
so yes, the best way will be to raise it (potentially also as product idea) and wait for it to be properly implemented.
I can't tell for sure from the top of my head, but it might be that the OneAgent (for .NET in beta for AppMon 7.0) already has a better handling for those requests in place.