Chapter “8.2. Asynchronous operations” in the specification states the following about Task Monitor for completed asynchronous operations: Once the operation has completed, the Task Monitor shall return a the appropriate status code ( OK 200 for most operations, Created 201 for POST to create a resource) and include the headers and response body of the initial operation, as if it had completed synchronously. If the initial operation resulted in an error, the body of the response shall contain an Error Response.
But this text only talks about the body of the response in case of error/failure scenario of the original asynchronous operation. HTTP status code to use in case of failure in the asynchronous operation is not explicitly described as far as I can see. Should I assume that the Task Monitor shall have a response with status codes, e.g. in series 400 or 500, corresponding to the failure reason of the original asynchronous operation? This seems to be a good approach as the Task Monitor would then be a clean “mirror” of the finished original asynchronous operation. But possible disadvantage with this approach could be that the client cannot distinguish between failure in the original asynchronous operation and failure in the Task Monitor request itself, at least based on the HTTP status code. (But maybe possible from error message in the Task Monitor response body.) What is the intended usage of the Task Monitor response status code in this case? Would you consider to clarify this in the specification?
If this was the failure of the Task that was spawned, the 4xx or 5xx would come back but the body would be more like something expected as if the response was synchronous. But some responses (like a Delete that was delayed) wouldn't have a real response body and may only have an error object. And if the error came back from some other reason, you could also only end up with an error object. So the answer is to look into the error object at the @message.ExtendedInfo for Messages and see the content. We should clarify the spec here. The messageArgs, in particular should have pointers to the actual problems. You always have the problem also that an error occurred at either end, so you have to prepare for handling that as well (for example, when the destination is unreachable).
OK, thanks for your reply. I still think you should consider to clarify this specification text related to the usage of Task Monitor response status codes in the case of failure in the asynchronous operation. (Most importantly from server/service implementation view. May question was actually not about how to act as a client.)