-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat(mqtt source): support multiple mqtt source topics #23670
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
base: master
Are you sure you want to change the base?
feat(mqtt source): support multiple mqtt source topics #23670
Conversation
+1 |
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.
Thanks for the contribution, this makes sense. Tests always appreciated :)
@pront can you take a look too?
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.
Left one optional suggestion.
} | ||
topic: { | ||
description: "MQTT topic from which messages are to be read." | ||
description: "MQTT topic or topics from which messages are to be read." |
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.
description: "MQTT topic or topics from which messages are to be read." | |
description: "MQTT topic(s) from which messages are read." |
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.
I don't mind either way. I wrote it as topic or topics
to make it a bit clearer that it could be specified as one or many (not just a single item of many for the former case)
I'm going to update the mqtt integration tests today then, as this PR appears to be approved. |
Summary
It would be good to be able to subscribe to multiple mqtt topics where we'd want to subscribe with eg
prefix-1/#
andprefix-2/#
mqtt topic specs, without receiving data from the broker with topics beginning withprefix-3...
(which would be a side effect of subscribing with the one topic spec string#
).This change doesn't break current tests, but I've held off on adding any new tests in case this PR will not be approved.
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changelog
label to this PR.