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

Relax validation on user-specified topic aliasing #334

Merged
merged 3 commits into from
Nov 9, 2023

Conversation

bretambrose
Copy link
Contributor

Being strict about topic alias validation seems counter productive. It's an optional micro-optimization and the client configuration may not be known to a user who may have to work with a client configured by a third party.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

local_publish_view.topic_alias = &outbound_topic_alias;
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Trivial: We could probably do without this log. I may be missing something but I don't think it's providing any useful information and the absence of the topic alias log above should be enough to infer that the publish isn't using topic aliasing. Also unsure whether we need to NULL

I think local_publish_view.topic_alias = NULL may be unnecessary. if outbound_topic_alias == 0, it's already NULL or an error was raised by the resolver. Could be missing something deeper tho.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

null assignment is necessary; up until now we're using what is specified by the user which could be an invalid mapping.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As an addendum, we're always in a better position if the logging tells us exactly what happened on its own, rather than having to read the log and the code and infer what happened based on what didn't show up in the logs.

@@ -1743,30 +1743,6 @@ static int s_aws_mqtt5_packet_publish_view_validate_vs_connection_settings(
return aws_raise_error(AWS_ERROR_MQTT5_PUBLISH_OPTIONS_VALIDATION);
}

if (publish_view->topic_alias != NULL) {
const struct aws_mqtt5_client_options_storage *client_options = client->config;
if (client_options->topic_aliasing_options.outbound_topic_alias_behavior != AWS_MQTT5_COTABT_USER) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Trivial: Not erroring here seems fine but should we log that we're ignoring?

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 feel like encoder logging gives a definitive answer to what we do alias-wise.

Copy link
Contributor

@sbSteveK sbSteveK left a comment

Choose a reason for hiding this comment

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

Trivial comments on logging

@bretambrose bretambrose merged commit 5d198cf into main Nov 9, 2023
@bretambrose bretambrose deleted the TopicAliasingPolish branch November 9, 2023 22:05
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