Based on the fact that there was 0 retries, I am betting that the operation never made to the network. The default for ResponseStatus is “Success” or 0; my guess it never was set and the default was returned. I don’t believe that is correct behavior but make sense in a way (see NCBC-3266).
I would enable logging and/or use the SDK Dr to help identify the cause of the timeout. The exception should have a ErrorContext field which may also help isolating the cause of the timeout
Looking at the RetryOrchestrator code, it simply isn’t setting the Status on the KeyValueErrorContext for timeouts. This is somewhat expected because Status is typically the value from the response from the server and there is no response in this case.
However, it does seem confusing. There is a Status value in the enumeration OperationTimeout, which is in the “client level failures” group. Unless this is against the SDK standards for some reason, I think we should set the Status to OperationTimeout in RetryOrchestrator when we throw.