mirror of
https://github.com/tinyhumansai/openhuman.git
synced 2026-07-27 21:08:00 +00:00
* fix(subconscious): seed defaults and spawn heartbeat on startup The subconscious engine was only constructed lazily on the first engine-routed RPC (trigger, tasks_add, status). Because handle_tasks_list bypasses the engine and reads the store directly, a fresh install showed an empty Subconscious panel until the user clicked "Run now", even though SubconsciousEngine::new() seeds the 3 default system tasks on construction. Separately, HeartbeatEngine::run() — the periodic tick loop — was never spawned in production code. The only callers of HeartbeatEngine were tests, so ticks never fired automatically; users had to trigger each evaluation manually. Both issues are fixed together in run_server_inner, following the existing start_if_enabled pattern used by voice, screen_intelligence, and autocomplete: 1. Call get_or_init_engine() at startup to construct the SubconsciousEngine eagerly, which runs seed_default_tasks via from_heartbeat_config. Construction is idempotent via OnceLock; seeding is idempotent by title match, so repeat startups do not duplicate the defaults. 2. Construct HeartbeatEngine with the heartbeat config and workspace_dir, then tokio::spawn heartbeat.run() so the periodic tick loop runs for the process lifetime. The loop re-acquires the shared engine via get_or_init_engine() on each tick. Guarded by config.heartbeat.enabled so users who disable the heartbeat get neither startup seeding nor the background loop. Add engine_construction_seeds_default_tasks integration test that locks in the invariant: constructing SubconsciousEngine on a fresh workspace_dir must leave the 3 default system tasks in the store, with no tick, trigger, or explicit seed call. Also asserts that reconstructing the engine on the same workspace does not duplicate the defaults. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(subconscious): defer engine bootstrap until after login Default system tasks seeded at sidecar startup into the pre-login global workspace (`~/.openhuman/workspace/`) instead of the per-user workspace (`~/.openhuman/users/<id>/workspace/`) the UI reads from after login. The engine singleton is built lazily via `get_or_init_engine()` and cached in a `OnceLock`. `Config::load_or_init` resolves `workspace_dir` from `active_user.toml` — which does not exist until after login. When the engine was constructed on startup it therefore seeded into the global default, then the frozen singleton kept pointing at that path for the rest of the session while RPC handlers like `tasks_list` re-loaded config per call and read from the correct per-user path, silently returning an empty list. Fix: - `subconscious/global.rs`: add `bootstrap_after_login()` (idempotent via `BOOTSTRAPPED: AtomicBool`) which builds the engine against the now-correct per-user workspace and spawns the heartbeat loop. Track the heartbeat `JoinHandle` in a static so it can be aborted cleanly. Add `reset_engine_for_user_switch()` that aborts the heartbeat, clears the engine option, and resets the bootstrap flag. - `core/jsonrpc.rs`: replace the unconditional eager init on startup with a conditional one that only bootstraps if `active_user.toml` already exists (so a user logged in from a previous session still gets the engine up immediately after restart). - `credentials/ops.rs`: call `bootstrap_after_login()` at the end of `verify_and_store_session` so a fresh login triggers seeding against the per-user workspace. Call `reset_engine_for_user_switch()` in `clear_session` so logout tears down the engine + heartbeat loop and a subsequent login rebuilds them against the new user. Verified locally: sidecar restart with no `active_user.toml` logs "bootstrap deferred — waiting for login"; post-login logs "seeded 3 tasks on init" + "heartbeat periodic loop spawned"; and `subconscious.tasks_list` returns the 3 system defaults from the per-user DB. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(subconscious): bound config load + guard frontend poll Two related fixes for the Intelligence page freezing on a stale subconscious activity-log snapshot while ticks kept progressing in the sidecar. Root cause (backend): the subconscious RPC handlers were the only outlier in the entire JSON-RPC surface that called the raw `Config::load_or_init()` instead of the shared `load_config_with_timeout()` wrapper that every other domain schemas.rs uses (cron, webhooks, voice, team, skills, service, referral, doctor, …). `load_or_init` constructs a fresh `SecretStore` and runs a chain of `decrypt_optional_secret` calls on every invocation, which may IPC to the OS keychain — slow, unbounded, no caching. Under the Intelligence page's 3-second poll (4 parallel RPCs × ~7 keychain round-trips each = ~28 keychain calls every 3s), this pileup was enough to pin the frontend's `Promise.all` past the poll interval. Root cause (frontend): `useSubconscious.refresh()` uses `fetchingRef` as an in-flight guard. The ref is only cleared inside the `finally` block that runs after `Promise.all` settles. With no per-RPC timeout on the client side either, a single slow backend call would leave the ref stuck `true`, and every subsequent 3s `setInterval` tick would silently early-return at the top of `refresh`. The poller kept firing, but every call was a no-op — so the UI froze on whatever snapshot it last successfully fetched, even though the backend was still ticking through new decisions. Backend fix (`src/openhuman/subconscious/schemas.rs`): - Replace the local `load_config()` helper body to delegate to `crate::openhuman::config::load_config_with_timeout()`. Matches the 28 other domain schemas.rs files and brings subconscious handlers under the same 30s bound used everywhere else. Frontend fix (`app/src/hooks/useSubconscious.ts`): - Add a `withTimeout` helper (2.5s per-RPC, strictly less than the 3s poll interval) that races each of the 4 parallel RPCs against a timeout and resolves `null` on timeout — matching the existing `.catch(() => null)` contract so downstream setState logic is unchanged. - Clear `fetchingRef.current = false` in the useEffect cleanup so a late-returning request or a React Strict Mode double-mount in dev can't leave the ref stuck `true` for the next mount. Defense in depth: the backend bound prevents a permanent hang and matches repo conventions, while the frontend bound guarantees the 3s poll loop can never be pinned beyond one tick regardless of server-side latency. Verified locally — `cargo check` clean, `tsc --noEmit` clean, all 18 pre-existing warnings in unrelated modules. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * style(jsonrpc): cargo fmt the startup bootstrap block CI ran `cargo fmt --all -- --check` and flagged the conditional bootstrap block in `run_server_inner` — `let already_logged_in` should fold onto one line, the `.and_then` closure body should inline, the `match ... .await` chain should fold, and the short log!() calls should not break across lines. No behavior change. Fixes three jobs on PR #462 that were all failing at the same `cargo fmt --all -- --check` step (Rust Quality, Rust Tests, Type Check TypeScript — the last one chains cargo fmt after its prettier check). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>