-
Notifications
You must be signed in to change notification settings - Fork 119
core:services:cable_guy: Fix _execute_route interface source #3647
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
core:services:cable_guy: Fix _execute_route interface source #3647
Conversation
Reviewer's guide (collapsed on small PRs)Reviewer's GuideAdjusts the Cable Guy manager’s _execute_route method to operate strictly on saved interface settings, adds validation for interface existence and type, and updates stored routes without re-fetching the interface from the system to avoid overwriting static configuration. Sequence diagram for updated _execute_route flow in CableGuyManagersequenceDiagram
participant Caller
participant CableGuyManager
participant SettingsStore
participant KernelRouting
Caller->>CableGuyManager: _execute_route(action, interface_name, route)
CableGuyManager->>CableGuyManager: is_valid_interface_name(interface_name, filter_wifi=true)
alt invalid_or_forbidden_interface
CableGuyManager-->>Caller: return (route action ignored)
else valid_interface
CableGuyManager->>SettingsStore: get_saved_interface_by_name(interface_name)
alt interface_not_found
CableGuyManager-->>Caller: raise ValueError
else interface_found
CableGuyManager->>CableGuyManager: _get_interface_index(interface_name)
CableGuyManager->>KernelRouting: apply route(action, interface_index, route)
alt routing_error
CableGuyManager-->>Caller: raise exception
else routing_ok
CableGuyManager->>CableGuyManager: get_routes(interface_name, ignore_unmanaged=false)
CableGuyManager->>SettingsStore: update current_interface.routes
CableGuyManager->>SettingsStore: sync managed flag on matching route
CableGuyManager-->>Caller: return
end
end
end
Updated class diagram for CableGuyManager _execute_route and related typesclassDiagram
class CableGuyManager {
+remove_route(interface_name: str, route: Route) void
-_execute_route(action: str, interface_name: str, route: Route) void
+is_valid_interface_name(interface_name: str, filter_wifi: bool) bool
+get_saved_interface_by_name(interface_name: str) Interface
+_get_interface_index(interface_name: str) int
+get_routes(interface_name: str, ignore_unmanaged: bool) list~Route~
}
class Interface {
+name: str
+routes: list~Route~
}
class Route {
+destination_parsed: str
+next_hop_parsed: str
+gateway: str
+next_hop_parsed: str
+managed: bool
}
CableGuyManager --> Interface : manages_saved_interfaces
CableGuyManager --> Route : configures_routes
Interface --> Route : has_routes
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
bd65b02 to
547eff4
Compare
* Make sure _execute_route use settings as source of the interface object to avoid fetching from system and overriding existing settings
547eff4 to
08d02c6
Compare
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.
Hey there - I've reviewed your changes - here's some feedback:
- Now that
_execute_routeraises aValueErrorwhenget_saved_interface_by_namereturnsNone, double-check that all callers either handle this exception or that it is acceptable for the caller path to fail hard rather than logging and continuing. - The new early return when
is_valid_interface_name(..., filter_wifi=True)fails changes behavior for Wi-Fi interfaces; confirm that this aligns with how higher-level code expects route ops for Wi-Fi to behave (e.g., if they previously relied on an error or different handling).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Now that `_execute_route` raises a `ValueError` when `get_saved_interface_by_name` returns `None`, double-check that all callers either handle this exception or that it is acceptable for the caller path to fail hard rather than logging and continuing.
- The new early return when `is_valid_interface_name(..., filter_wifi=True)` fails changes behavior for Wi-Fi interfaces; confirm that this aligns with how higher-level code expects route ops for Wi-Fi to behave (e.g., if they previously relied on an error or different handling).
## Individual Comments
### Comment 1
<location> `core/services/cable_guy/api/manager.py:638-639` </location>
<code_context>
self._execute_route("del", interface_name, route)
def _execute_route(self, action: str, interface_name: str, route: Route) -> None:
+ if not self.is_valid_interface_name(interface_name, filter_wifi=True):
+ logger.debug(f"Ignoring route action '{action}' for forbidden interface '{interface_name}'.")
+ return
+
</code_context>
<issue_to_address>
**question (bug_risk):** Consider whether silently ignoring route actions for filtered interfaces is the right contract here.
This early return changes `_execute_route` from "attempt and likely fail" to "no-op with a debug log" for some interfaces. If callers depended on an exception or other failure signal for invalid/forbidden interfaces, this could hide misconfigurations and upstream logic bugs. Please confirm that callers expect a no-op here; otherwise consider raising a clear exception or performing this check explicitly at call sites instead.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
This could be the fix for root cause of static IPs being lost on PI5 due to fact that NetworkManager take more time to apply configuration and during cable guy startup sequence
_execute_routemethod could be some times being called prior to IP addresses been actually configured properly.Summary by Sourcery
Ensure cable_guy route execution uses saved interface settings as the authoritative source and skips invalid or forbidden interfaces when applying route changes.
Bug Fixes: