Skip to content

MQTT Topic Filter Support #2690

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

bretambrose
Copy link

Background

Adds support (parsing, validation, conflict-checking) for traits to reference MQTT topic filters. Topic filter support is required for the new request-response MQTT service clients being released by the IoT SDKs.

Fixes a bug where the topic parser incorrectly skips a trailing or preceding empty topic level.

Testing

  • Tests have been added for topic filter parsing and conflict checking.
  • Tests have been added to cover initial and trailing empty topic levels.

Links


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

Bret Ambrose added 2 commits July 1, 2025 10:05
Adds support (parsing, validation, conflict-checking) for traits to reference MQTT topic filters, which allow single-level and multi-level wildcard expressions.  Further information about topics and topic filters can be found in MQTT specification docs: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901241

Fixes a bug where the topic parser incorrectly skip a trailing or preceding empty topic level.
@bretambrose bretambrose requested a review from a team as a code owner July 1, 2025 18:19
@bretambrose bretambrose requested a review from joewyz July 1, 2025 18:19
Comment on lines +187 to +194
// Note: I disagree with the above assertion and what it implies for the definition (which is not
// given anywhere) of "topic conflict." My definition of "topic conflict" is "could potentially have
// a non-empty routing intersection."
//
// In particular, the above check can lead to a non-empty intersection if the label substitution
// yields a value that matches the non-label level's value.
//
// Despite this, I don't want to change the behavior of what currently exists.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please move this note to an issue instead? Having it here is confusing and difficult to find to improve whatever the current situation is.

@@ -21,32 +21,73 @@
public final class Topic {
private static final Pattern LABEL_PATTERN = Pattern.compile("^[a-zA-Z0-9_]+$");

private final TopicRule rule;
Copy link
Contributor

Choose a reason for hiding this comment

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

The rule is only used for parsing. This field is never used, let's remove it.

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