Feature/shared hubs - #83
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6e79b3ccd9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (shockerList.ContainsKey(shockerId)) continue; | ||
|
|
||
| // Shared shockers are present in the permission map; owned shockers are not. | ||
| var enabled = !_sharedShockerPermissions.ContainsKey(shockerId); |
There was a problem hiding this comment.
When a shared shocker is first discovered, this defaults Enabled to false, but the only enable checkbox I found is in Desktop/Ui/Pages/Dash/Tabs/ShockersTab/ShockersTab.razor and it renders only OpenShockApi.Hubs.Value.SelectMany(...), i.e. owned hubs. In the normal UI flow a newly shared shocker therefore stays disabled forever, so BackendHubManager.CanControl and IsLiveControllable filter it out even when the user has permissions; include shared shockers in the opt-in UI or provide another persisted opt-in path.
Useful? React with 👍 / 👎.
| await _apiClient.RefreshHubs(); | ||
| await _apiClient.RefreshSharedHubs(); |
There was a problem hiding this comment.
On startup or re-auth, SharedHubs is still empty when RefreshHubs() runs, so its SyncShockerConfig() rewrites and saves Config.OpenShock.Shockers with only owned IDs before this newly added shared refresh happens. The subsequent RefreshSharedHubs() call no longer sees any saved Enabled=true entries for shared shockers and re-adds them as default-disabled, so any prior opt-in/manual config for shared shockers is lost on every login; defer the sync/save until both owned and shared responses are loaded or preserve existing shared entries during the owned refresh.
Useful? React with 👍 / 👎.
| // Frames are only accepted once the socket is connected; while it is still warming up (or reconnecting) we | ||
| // drop them. EnsureConnection already kicked off / kept the connection alive. | ||
| if (connection.Client.State.Value != WebsocketConnectionState.Connected) return; |
There was a problem hiding this comment.
With the new lazy connection flow, the first call to LiveControl or ControlAllShockers creates the socket and immediately reaches this guard while the client is still connecting, so the frame is dropped instead of being passed to IntakeFrame. A short one-frame live-control burst now does nothing unless another frame arrives after the connection finishes; either wait/queue the frame or keep clients warm before accepting live-control calls.
Useful? React with 👍 / 👎.
| if (_apiClient.SharedShockerPermissions.TryGetValue(shockerId, out var permissions)) | ||
| return permissions.Live; |
There was a problem hiding this comment.
For a shared shocker with Live=true but without the requested Shock, Vibrate, or Sound permission, this filter still allows the shocker through because it ignores the type passed to ControlShockers. The regular control path checks the action-specific permission, so live control can attempt frames the share owner did not grant or trigger server-side rejections for those permission combinations; include the requested control type in this check.
Useful? React with 👍 / 👎.
1 participant
No description provided.