- Fix panic recovery in AddSession to log instead of re-throwing, preventing process crashes
- Fix integer overflow in trust score calculation by capping before int conversion
- Fix TOCTOU race condition in nickname uniqueness check with atomic UpdateSessionNickname method
- Fix nickname index stale pointer during session reconnection
- Reset LastActive for all emergency promotions to prevent cascade timeouts
- Bypass rate limits when no primary exists to prevent system deadlock
- Replace manual mutex with atomic.Int32 for session counter (fixes race condition)
- Implement collect-then-delete pattern for safe map iteration
- Reduce logging verbosity for routine cleanup operations
Problem: The jiggler was calling sessionManager.UpdateLastActive() which
prevented the primary session timeout from ever triggering. This made it
impossible to automatically demote inactive primary sessions.
Root cause analysis:
- Jiggler is automated mouse movement to prevent remote PC sleep
- It was incorrectly updating LastActive timestamp as if it were user input
- This reset the inactivity timer every time jiggler ran
- Primary session timeout requires LastActive to remain unchanged during
actual user inactivity
Changes:
- Removed sessionManager.UpdateLastActive() call from jiggler.go:145
- Added comment explaining why jiggler should not update LastActive
- Session timeout now correctly tracks only REAL user input:
* Keyboard events (via USB HID)
* Mouse events (via USB HID)
* Native operations
- Jiggler mouse movement is explicitly excluded from activity tracking
This works together with the previous fix that removed LastActive reset
during WebSocket reconnections.
Impact:
- Primary sessions will now correctly timeout after configured inactivity
- Jiggler continues to prevent remote PC sleep as intended
- Only genuine user input resets the inactivity timer
Test:
1. Enable jiggler with short interval (e.g., every 10 seconds)
2. Set primary timeout to 60 seconds
3. Leave primary tab in background with no user input
4. Jiggler will keep remote PC awake
5. After 60 seconds, primary session is correctly demoted
Fixed critical bug where primary session timeout was never triggered even
after configured inactivity period (e.g., 60 seconds with no input).
Root cause: LastActive timestamp was being reset during WebSocket
reconnections and session promotions, preventing the inactivity timer
from ever reaching the timeout threshold.
Changes:
- session_manager.go:245: Removed LastActive reset during reconnection
in AddSession(). Reconnections should NOT reset the activity timer
since timeout is based on input activity, not connection activity.
- session_manager.go:1207-1209: Made LastActive reset conditional in
transferPrimaryRole(). Only emergency promotions reset the timer to
prevent immediate re-timeout. Manual transfers preserve existing
LastActive for accurate timeout tracking.
Impact:
- Primary sessions will now correctly timeout after configured inactivity
- LastActive only updated by actual user input (keyboard/mouse events)
- Emergency promotions still get fresh timer to prevent rapid re-timeout
- Manual transfers maintain accurate activity tracking
Test scenario:
1. User becomes primary and leaves tab in background
2. No keyboard/mouse input for 60+ seconds (timeout configured)
3. WebSocket stays connected but LastActive is not reset
4. handlePrimarySessionTimeout() detects inactivity and demotes primary
5. Next eligible observer is automatically promoted
This commit addresses three critical issues discovered during testing:
Issue 1 - Intermittent mouse control loss requiring page refresh:
When a session was promoted to primary, the HID queue handlers were fetching
a fresh session copy from the session manager instead of using the original
session pointer. This meant the queue handler had a stale Mode field (observer)
while the manager had the updated Mode (primary). The permission check would
fail, silently dropping all mouse input until the page was refreshed.
Issue 2 - Missing permission failure diagnostics:
When keyboard/mouse input was blocked due to insufficient permissions, there
was no debug logging to help diagnose why input wasn't working. This made
troubleshooting observer mode issues extremely difficult.
Issue 3 - Session timeout despite active jiggler:
The server-side jiggler moves the mouse every 30s after inactivity to prevent
screen savers, but wasn't updating the session's LastActive timestamp. This
caused sessions to timeout after 60s even with the jiggler active.
Issue 4 - Session flapping after emergency promotion:
When a session timed out and another was promoted, the newly promoted session
had a stale LastActive timestamp (60+ seconds old), causing immediate re-timeout.
This created an infinite loop where both sessions rapidly alternated between
primary and observer every second.
Issue 5 - Unnecessary WebSocket reconnections:
The WebSocket fallback was unconditionally closing and reconnecting during
emergency promotions, even when the connection was healthy. This caused
spurious "Connection Issue Detected" overlays during normal promotions.
Changes:
- webrtc.go: Use original session pointer in handleQueues() (line 197)
- hidrpc.go: Add debug logging when permission checks block input (lines 31-34, 61-64, 75-78)
- jiggler.go: Update primary session LastActive after mouse movement (lines 146-152)
- session_manager.go: Reset LastActive to time.Now() on promotion (line 1090)
- devices.$id.tsx: Only reconnect if connection is unhealthy (lines 413-425)
This ensures:
1. Queue handlers always have up-to-date session state
2. Permission failures are visible in logs for debugging
3. Jiggler prevents both screen savers AND session timeout
4. Newly promoted sessions get full timeout period (no immediate re-timeout)
5. Emergency promotions only reconnect when connection is actually stale
6. No spurious "Connection Issue" overlays during normal promotions
The jiggler sends keep-alive packets every 50ms to prevent keyboard
auto-release, but wasn't updating the session's LastActive timestamp.
This caused the backend to timeout and demote the primary session after
5 minutes (default primaryTimeout), even with active jiggler.
Primary fix:
- Add UpdateLastActive call to handleHidRPCKeepressKeepAlive() in hidrpc.go
- Ensures jiggler packets prevent session timeout
Defensive enhancement:
- Add WebSocket fallback for emergency promotion signals in session_manager.go
- Store WebSocket reference in Session struct (webrtc.go)
- Handle connectionModeChanged via WebSocket in devices.$id.tsx
- Provides reliable signaling when WebRTC data channel is stale
Add two new configurable session settings to improve multi-session management:
1. Maximum Concurrent Sessions (1-20, default: 10)
- Controls the maximum number of simultaneous connections
- Configurable via settings UI with validation
- Applied in session manager during session creation
2. Observer Cleanup Timeout (30-600 seconds, default: 120)
- Automatically removes inactive observer sessions with closed RPC channels
- Prevents accumulation of zombie observer sessions
- Runs during periodic cleanup checks
- Configurable timeout displayed in minutes in UI
Backend changes:
- Add MaxSessions and ObserverTimeout fields to SessionSettings struct
- Update setSessionSettings RPC handler to persist new settings
- Implement observer cleanup logic in cleanupInactiveSessions
- Apply maxSessions limit in NewSessionManager with proper fallback chain
Frontend changes:
- Add numeric input controls for both settings in multi-session settings page
- Include validation and user-friendly error messages
- Display friendly units (sessions, seconds/minutes)
- Maintain consistent styling with existing settings
Also includes defensive nil checks in writeJSONRPCEvent to prevent
"No HDMI Signal" errors when RPC channels close during reconnection.
This commit addresses multiple CRITICAL and HIGH severity security issues
identified during the multi-session implementation review.
CRITICAL Fixes:
- Fix race condition in session approval handlers (jsonrpc.go)
Previously approveNewSession and denyNewSession directly mutated
session.Mode without holding the SessionManager.mu lock, potentially
causing data corruption during concurrent access.
- Add validation to ApprovePrimaryRequest (session_manager.go:795-810)
Now verifies that requester session exists and is in Queued mode
before approving transfer, preventing invalid state transitions.
- Close dual-primary window during reconnection (session_manager.go:208)
Added explicit primaryExists check to prevent brief window where two
sessions could both be primary during reconnection.
HIGH Priority Fixes:
- Add nickname uniqueness validation (session_manager.go:152-159)
Prevents multiple sessions from having the same nickname, both in
AddSession and updateSessionNickname RPC handler.
Code Quality:
- Remove debug scaffolding from cloud.go (lines 515-520, 530)
Cleaned up temporary debug logs that are no longer needed.
Thread Safety:
- Add centralized ApproveSession() method (session_manager.go:870-890)
- Add centralized DenySession() method (session_manager.go:894-912)
Both methods properly acquire locks and validate session state.
- Update RPC handlers to use thread-safe methods
approveNewSession and denyNewSession now call sessionManager methods
instead of direct session mutation.
All changes have been verified with linters (golangci-lint: 0 issues).
The session manager had backwards logic that prevented sessions from
restoring their primary status when reconnecting within the grace period.
This caused browser refreshes to demote primary sessions to observers.
Changes:
- Fix conditional in AddSession to allow primary restoration within grace
- Remove excessive debug logging throughout session manager
- Clean up unused decrActiveSessions function
- Remove unnecessary leading newline in NewSessionManager
- Update lastPrimaryID handling to support WebRTC reconnections
- Preserve grace periods during transfers to allow browser refreshes
The fix ensures that when a primary session refreshes their browser:
1. RemoveSession adds a grace period entry
2. New connection checks wasWithinGracePeriod and wasPreviouslyPrimary
3. Session correctly reclaims primary status
Blacklist system prevents demoted sessions from immediate re-promotion
while grace periods allow legitimate reconnections.
When a primary session disconnects accidentally (not intentional logout), the
60-second transfer blacklist from previous role transfers was blocking observer
sessions from being promoted after the grace period expires (~10s).
The blacklist is intended to prevent immediate re-promotion during manual
transfers (user-initiated), but should not interfere with emergency promotion
after accidental disconnects (system-initiated).
Changes:
- Clear all transfer blacklist entries when primary enters grace period
- Add logging to track blacklist clearing for debugging
- Preserve blacklist during intentional logout to maintain manual transfer protection
This ensures observers are promoted after grace period (~10s) instead of
waiting for blacklist expiration (~40-60s).
1. Terminal access permission check:
- Add Permission.TERMINAL_ACCESS check to Web Terminal button
- Prevents observer sessions from accessing terminal
2. Immediate websocket cleanup:
- Close peer connection immediately when websocket errors
- Previously waited 24+ seconds for ICE to transition from disconnected to failed
- Now triggers session cleanup immediately on tab close
3. Immediate grace period validation:
- Trigger validateSinglePrimary() immediately when grace period expires
- Previously waited up to 10 seconds for next periodic validation
- Eliminates unnecessary delay in observer promotion
Timeline improvement:
Before: Tab close → 6s (ICE disconnect) → 24s (ICE fail) → RemoveSession → 10s grace → up to 10s validation = ~50s total
After: Tab close → immediate peerConnection.Close() → immediate RemoveSession → 10s grace → immediate validation = ~11s total
Add comprehensive logging to identify why sessions fail to be added to
the session manager:
- Log entry/exit points in AddSession
- Track reconnection path execution
- Log max sessions limit checks
- Trace AddSession call and return in handleSessionRequest
This will help diagnose why sessions get stuck at ICE checking state
without being properly registered in the session manager.
Observer-to-primary promotion protections:
- Block auto-promotion during active primary grace periods
- Prevent creating multiple primary sessions simultaneously
- Validate transfer source is actual current primary
- Check for duplicate primaries before promotion
Immediate promotion on logout:
- Trigger validateSinglePrimary() immediately when primary disconnects
- Smart grace period bypass: allow promotion within 2 seconds of disconnect
- Provides instant promotion on logout while protecting against network blips
Enhanced validation and logging:
- Log session additions/removals with counts
- Display session IDs in validation logs for debugging
- Track grace period timing for smart bypass decisions
Backend improvements:
- Keep denied sessions alive in pending mode instead of removing them
- Add requestSessionApproval RPC method for re-requesting access
- Fix security issue: preserve pending mode on reconnection for denied sessions
- Add MaxRejectionAttempts field to SessionSettings (default: 3, configurable 1-10)
Frontend improvements:
- Change "Try Again" button to "Request Access Again" that re-requests approval
- Add rejection counter with configurable maximum attempts
- Hide modal after max rejections; session stays pending in SessionPopover
- Add "Dismiss" button for primary to hide approval requests without deciding
- Add MaxRejectionAttempts control in multi-session settings page
- Reset rejection count when session is approved
This improves the user experience by allowing denied users to retry without
page reloads, while preventing spam with configurable rejection limits.
Address all linting warnings and errors in both backend and frontend code:
**Go (golangci-lint):**
- Add error checking for ignored return values (errcheck)
- Remove unused RPC functions (unused)
- Fix import formatting (goimports)
**TypeScript/React (eslint):**
- Replace all 'any' and 'Function' types with proper type definitions
- Add RpcSendFunction type for consistent JSON-RPC callback signatures
- Fix React Hook exhaustive-deps warnings by adding missing dependencies
- Wrap functions in useCallback where needed to stabilize dependencies
- Remove unused variables and imports
- Remove empty code blocks
- Suppress exhaustive-deps warnings where intentional (with comments)
All linting now passes with 0 errors and 0 warnings.
Alex P