Skip to content
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

rethrow MqttClientUnexpectedDisconnectReceivedException when Publish … #1974

Merged

Conversation

fazho
Copy link
Contributor

@fazho fazho commented Apr 22, 2024

rethrow MqttClientUnexpectedDisconnectReceivedException when QoS is 0 and Publish errors out because server disconnects the client.

…errors out because server disconnects the client and QoS is 0
@fazho fazho marked this pull request as draft April 22, 2024 17:13
@fazho fazho marked this pull request as ready for review April 22, 2024 18:03
@fazho fazho marked this pull request as draft April 22, 2024 18:04
@fazho fazho marked this pull request as ready for review April 22, 2024 18:04
@fazho
Copy link
Contributor Author

fazho commented Apr 22, 2024

@chkr1011 fyi

}
catch (Exception)
{
if (_unexpectedDisconnectPacket != null)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this only apply for QoS 0? I am wondering if this code must be also used for QoS 1 and 2?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it only applies to QoS 0 because for QoS 1, the client actually registers an awaitable and wait for the response packet, so it already throws an exception with the error code as of today. But for QoS 0, the client does not register any awaitable. I guess this is by design because QoS 0 should not expect any response from server. But QoS 1 can always expect some response, whether its a PUBACK or DISCONNECT

@fazho
Copy link
Contributor Author

fazho commented Apr 25, 2024

@chkr1011 any thoughts on the concern I raised? Or if not, can you approve this PR?

return MqttClientResultFactory.PublishResult.Create(null);
if (localUnexpectedDisconnectPacket != null)
{
throw new MqttClientUnexpectedDisconnectReceivedException(localUnexpectedDisconnectPacket);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would pass the actual exception to the inner exception so that it is still accessible for the user.

@chkr1011
Copy link
Collaborator

chkr1011 commented May 1, 2024

I will add the breaking change to the release notes. Breaking changes are happening from time to time and cannot be avoided. In this case we still get an exception. Only the the type is different now. I added a comment to the code.

@chkr1011
Copy link
Collaborator

chkr1011 commented May 4, 2024

@fazho I made the change myself and also updated the release notes and added a comment. Please let me know if you agree with the changes (especially the comment). After that I will merge the PR.

@fazho
Copy link
Contributor Author

fazho commented May 6, 2024

@chkr1011 your changes look good to me. I just made another small change, setting the default inner exception as null in the constructor of MqttClientUnexpectedDisconnectReceivedException, so that if anyone explicitly creates an MqttClientUnexpectedDisconnectReceivedException object in their code (e.g., someone might mock the MQTTClient and create this exception in their unit tests), our changes in this PR will not break it.

I know this will be a breaking change either way, but just try to make the breaking part minimum.

@fazho
Copy link
Contributor Author

fazho commented May 6, 2024

@chkr1011 feel free to revert my latest change if it does not make sense to you. I am ok either way.

@chkr1011 chkr1011 self-assigned this May 7, 2024
@chkr1011 chkr1011 merged commit abbf14b into dotnet:master May 7, 2024
1 check passed
@fazho fazho deleted the fazho/wrap-disconnect-info-in-publish-exception branch May 7, 2024 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants