fix(edge-client): subscribe control/set topics for every PLC, not just the first - #2
Merged
Merged
Conversation
…t the first With two PLCs on one edge-client, only the first PLC was controllable. build_subscribe_patterns skipped every DeviceType::Master assuming they were covered by the machine patterns, but those only cover the primary PLC (machine_id = first PLC). Additional PLCs' control/set topics were never subscribed, so their commands never arrived. Skip only the first PLC (matching primary_plc_registered in from_settings); additional PLCs now get their own patterns like slaves do. Make the function a pure fn (base, machine, mapping) and add a real regression test — the existing subscribe-patterns test never called the function, which is how this shipped.
There was a problem hiding this comment.
Pull request overview
Fixes multi-PLC control by ensuring the control subscriber subscribes to control/# and set/# topics for every PLC (not just the primary/first one), preventing commands for additional PLCs from being dropped before dispatch.
Changes:
- Refactored
build_subscribe_patternsto a pure function taking(base, machine, mapping)instead of&Settings. - Updated subscription pattern generation to skip only the primary PLC (first
DeviceType::Master) and include additional PLCs. - Added a regression unit test covering the “second PLC not subscribed” scenario.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+184
to
+188
| for device in &mapping.devices { | ||
| use crate::shared::DeviceType; | ||
| if device.device_type == DeviceType::Master { | ||
| continue; // PLC already covered by machine patterns above | ||
| if device.device_type == DeviceType::Master && !primary_plc_skipped { | ||
| primary_plc_skipped = true; | ||
| continue; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
With two PLCs on one edge-client, only the first PLC was controllable. Commands to the second PLC were published fine but never acted on.
build_subscribe_patternsskipped everyDeviceType::Master, assuming they were already covered by the machine patterns ({base}/{machine}/control/#). But those only cover the primary PLC (machine_id= first PLC). Additional PLCs'control/#andset/#topics were never subscribed, so their messages never reached the dispatcher.Fix
Skip only the first PLC (matching
primary_plc_registeredinfrom_settings). Additional PLCs now get their own patterns, just like slaves.build_subscribe_patternsto a pure fn (base,machine,mapping) so it can be unit-tested without env.Test
cargo build,cargo clippy --all-targets,cargo test— all clean (122 tests).