Skip to main content
The Palyra Desktop Companion acts as a high-level supervisor for the core daemon and its associated sidecar processes. This lifecycle management is centered around the ControlCenter struct, which maintains the desired state of the system, manages process execution with exponential backoff, and aggregates logs and diagnostics for the operator.

ControlCenter Supervisor Loop

The ControlCenter is the central orchestrator within the Tauri-based desktop application. It manages three primary ManagedService instances: gateway (palyrad), browserd (palyra-browserd), and the node_host (palyra node host) apps/desktop/src-tauri/src/supervisor.rs#225-227. The supervisor operates on a periodic tick defined by SUPERVISOR_TICK_MS (500ms) apps/desktop/src-tauri/src/lib.rs#1. During each tick, it evaluates the liveness of child processes and attempts to reconcile their actual state with the desired_running configuration apps/desktop/src-tauri/src/supervisor.rs#109-110.

ManagedService and ServiceKind

Every supervised process is encapsulated in a ManagedService struct apps/desktop/src-tauri/src/supervisor.rs#108-118. This struct tracks: Services are identified by the ServiceKind enum apps/desktop/src-tauri/src/supervisor.rs#37-41:
ServiceKindBinary NameRole
GatewaypalyradCore daemon, hosts GatewayService and HTTP APIs.
Browserdpalyra-browserdHeadless Chromium management via CDP.
NodeHostpalyra node hostLocal capability execution and pairing.
Sources: apps/desktop/src-tauri/src/supervisor.rs#35-118, apps/desktop/src-tauri/src/lib.rs#1-3

Supervisor Data Flow

The following diagram illustrates the relationship between the ControlCenter and the underlying OS processes. Supervisor Process Architecture Sources: apps/desktop/src-tauri/src/supervisor.rs#108-234, apps/desktop/src-tauri/src/lib.rs#1-3

Restart Strategy and Backoff

To prevent resource exhaustion during crash loops, the ControlCenter implements an exponential backoff strategy. When a service exits unexpectedly while desired_running is true, the supervisor increments the restart_attempt counter apps/desktop/src-tauri/src/supervisor.rs#113. The backoff duration is calculated using compute_backoff_ms, which increases the delay between attempts based on the failure count apps/desktop/src-tauri/src/tests.rs#34 (Note: implementation details in supervisor.rs). This ensures that failing services do not saturate system CPU or logs. Sources: apps/desktop/src-tauri/src/supervisor.rs#108-148, apps/desktop/src-tauri/src/tests.rs#33-42

Log Aggregation and Path Resolution

Log Aggregation via MPSC Channels

The supervisor uses tokio::sync::mpsc channels to aggregate logs from all managed services.
  1. Transmission: Each service’s stdout and stderr are piped into BufReader apps/desktop/src-tauri/src/supervisor.rs#17-18.
  2. Collection: Lines are wrapped in a LogEvent struct containing the ServiceKind, LogStream (Stdout/Stderr/Supervisor), and a timestamp apps/desktop/src-tauri/src/supervisor.rs#100-106.
  3. Buffering: Events are sent to ControlCenter.log_tx apps/desktop/src-tauri/src/supervisor.rs#231.
  4. Sanitization: Before being stored or displayed in the UI, lines are passed through sanitize_log_line to redact sensitive information apps/desktop/src-tauri/src/snapshot.rs#38.

Binary Path Resolution

The supervisor resolves binary paths using resolve_binary_path apps/desktop/src-tauri/src/supervisor.rs#45. It follows a specific priority:
  1. Environment Overrides: Checks for variables like PALYRA_DESKTOP_PALYRAD_BIN apps/desktop/src-tauri/src/supervisor.rs#66.
  2. Colocated Binaries: Looks for binaries in the same directory as the desktop executable apps/desktop/README.md#121-124.
  3. System Path: Falls back to standard executable resolution apps/desktop/src-tauri/src/supervisor.rs#60-62.
Sources: apps/desktop/src-tauri/src/supervisor.rs#17-106, apps/desktop/src-tauri/src/snapshot.rs#34-40, apps/desktop/README.md#121-129

State Persistence and Migration

The desktop application persists its configuration and the supervisor’s state in a JSON file defined by the DesktopStateFile struct apps/desktop/src-tauri/src/desktop_state.rs#214-226.

Schema Versioning

The state file includes a schema_version to handle migrations. The current version is defined by DESKTOP_STATE_SCHEMA_VERSION (version 6) apps/desktop/src-tauri/src/lib.rs#9. When the application loads, it calls load_or_initialize_state_file to read the file from the desktop-control-center directory apps/desktop/src-tauri/src/lib.rs#36-41.

Data Entities

The following diagram maps the logical state entities to their code representations. State Entity Mapping

Runtime Secrets

Secrets such as the admin_token and browser_auth_token are managed separately from the main state file. They are loaded via load_runtime_secrets apps/desktop/src-tauri/src/lib.rs#37 and stored in the DesktopSecretStore apps/desktop/src-tauri/src/desktop_state.rs#40. Migration logic in migrate_legacy_runtime_secrets_from_state_file handles moving secrets out of the primary state file into a secure storage backend if they were present in older versions apps/desktop/src-tauri/src/lib.rs#38. Sources: apps/desktop/src-tauri/src/desktop_state.rs#210-230, apps/desktop/src-tauri/src/lib.rs#9-41, apps/desktop/README.md#61-79