Skip to content

[Bug] Service Required screen: Load failed and buttons disabled on app startup #129

Closed

Description

@graycyrus

Summary

On app startup, the "OpenHuman Service Required" screen shows "Load failed" and all action buttons (Install, Start, Stop, Restart, Uninstall) are disabled — the user is stuck with no way to recover.

Problem

What happened: App launches to the Service Required gate screen. It attempts to connect to the core daemon at http://127.0.0.1:7788/rpc and fails. A red "Load failed" banner appears. All buttons except Refresh are grayed out and unclickable.

What was expected: The Install Service and Start Service buttons should be usable so the user can bootstrap the daemon from this screen.

Impact: Blocks the entire app — user cannot get past this screen.

Steps to reproduce:

  1. Fresh install of the app (or core daemon not running)
  2. Launch the app
  3. "OpenHuman Service Required" screen appears
  4. Service: Unknown, Agent Server: Not Running, "Load failed" in red
  5. All buttons disabled except Refresh

Platform: macOS (desktop)

Solution

Root cause: Catch-22 in ServiceBlockingGate.tsx. When the RPC health check fails:

  1. Service state is set to "Unknown"
  2. The button disable logic derives installed = (serviceStateText !== 'NotInstalled') — but "Unknown" doesn't match any known state, so installed resolves to false in practice
  3. Most buttons require installed === true to be enabled (Install requires !installed, but it also requires the RPC to succeed to execute)
  4. The buttons that should help recover (Install, Start) are disabled by the very state they need to fix

Proposed fix:

  1. Enable Install and Start buttons when state is "Unknown" — these are the recovery actions and should always be clickable
  2. Clear error banner on retry — currently the error persists even if the user clicks Refresh
  3. Route Install/Start through Tauri commands directly instead of RPC when the daemon isn't reachable — the RPC server is the daemon itself, so you can't ask it to install/start itself if it's not running

Key files:

  • app/src/components/daemon/ServiceBlockingGate.tsx — gate component with button disable logic
  • app/src/services/coreRpcClient.ts — RPC client hitting :7788
  • app/src-tauri/src/core_process.rs — core process management
  • src/openhuman/service/macos.rs — macOS LaunchAgent install/start
  • src/openhuman/service/common.rs — daemon executable resolution

Acceptance criteria

  • Install Service and Start Service buttons are enabled when service state is Unknown or Load failed
  • Error banner clears when user retries or clicks a button
  • Service can be installed and started from the blocked screen without the daemon already running
  • Repro gone — fresh install shows working buttons on the Service Required screen
  • Regression safety — existing service management flows still work when daemon is already running

Related

Priority: High — blocks app startup for new users.

Activity

  1. zahica1234 commented on May 11, 2026

    @zahica1234
    Contributor

    Same on Windows v0.53.22 (x64), reproduced with both installers.

    Both OpenHuman_0.53.22_x64_en-US.msi and OpenHuman_0.53.22_x64-setup.exe install
    identical contents to %LOCALAPPDATA%\OpenHuman\. No core daemon binary is shipped.

    Diagnostic evidence:

    1. Only one .exe with the OpenHuman name in the install dir: OpenHuman.exe (110 MB, the UI).
    2. The other two .exe files (bootstrap.exe, bootstrapc.exe, 2.8 MB each) report
      themselves as "CEF Bootstrap Application" (Chromium 146.0.7680.165) in VersionInfo
      and crash with [FATAL:cef/libcef_dll/bootstrap/bootstrap_win.cc:387] Missing module name
      when run standalone. They're not the Rust core.
    3. Disk-wide search across C:\ and D:\ for openhuman*.exe and openhuman-core*.exe
      returns only OpenHuman.exe and the downloaded installers.
    4. The install contains _up_\_up_\src\openhuman\agent\prompts\*.rs source files —
      suggests a path-traversal issue in the build script's resource bundling.
    5. App also bundles libcef.dll (262 MB), which contradicts the README's "Rust/Tauri"
      architecture (Tauri targets WebView2 on Windows, not CEF).

    Result: app launches to "Service Required" → "Load failed", all buttons disabled,
    no way to install/start a service because the daemon binary is not present on disk.

    Service Required screen recovery (the original bug) is one issue, but a more fundamental
    packaging bug is sitting underneath it on Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions