-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse service error fot get twin failures - mqtt #2999
Conversation
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
if (Enum.TryParse(getTwinResponse.ErrorResponseMessage.ErrorCode.ToString(), out IotHubClientErrorCode errorCode) | ||
|| Enum.TryParse(getTwinResponse.Status.ToString(), out errorCode)) | ||
{ | ||
throw new IotHubClientException(getTwinResponse.ErrorResponseMessage.Message, errorCode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea on whether we can make it retriable or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on the error code returned IotHubClientException will mark it as transient. That is the only way for us to mark a scenario as retriable.
Note that networking issues won't fit into this scenario as they will not result in a GetTwinResponse
. This logic only looks at the Status within GetTwinResponse to parse out the error code.
Networking issues will still be handled here:
azure-iot-sdk-csharp/iothub/device/src/Transport/Mqtt/MqttTransportHandler.cs
Lines 649 to 670 in 5508c16
catch (MqttCommunicationTimedOutException ex) when (!cancellationToken.IsCancellationRequested) | |
{ | |
// This execption may be thrown even if cancellation has not been requested yet. | |
// This case is treated as a timeout error rather than an OperationCanceledException | |
throw new IotHubClientException( | |
MessageTimedOutErrorMessage, | |
IotHubClientErrorCode.Timeout, | |
ex); | |
} | |
catch (MqttCommunicationTimedOutException ex) when (cancellationToken.IsCancellationRequested) | |
{ | |
// MQTTNet throws MqttCommunicationTimedOutException instead of OperationCanceledException | |
// when the cancellation token requests cancellation. | |
throw new OperationCanceledException(MessageTimedOutErrorMessage, ex); | |
} | |
catch (Exception ex) when (ex is not IotHubClientException && ex is not OperationCanceledException) | |
{ | |
throw new IotHubClientException( | |
"Failed to get the twin.", | |
IotHubClientErrorCode.NetworkErrors, | |
ex); | |
} |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Related #2967
Our transport layer currently isn't inspecting and parsing out the service returned error message over AMQP and MQTT. Instead, the entire error "message" block containing the error code, description, tracking Id etc. is put into IotHubClientException.Message. This leaves the parsing responsibility onto the customer.
This PR proposes a change where we inspect the received error message and parse it out.
Another related issue is that as a result of us not parsing out the error message, we currently mark all unsuccessful MQTT twin operations as retryable. This results in the actual error being hidden from the user and the SDK unnecessarily retying non-retryable error scenarios.
This PR also adds back the error parsing logic from here: https://github.com/Azure/azure-iot-sdk-csharp/blob/main/iothub/device/src/Transport/Mqtt/MqttTransportHandler.cs#L1130-L1143