Files
openhuman/app/src
9764a875e8 fix(subconscious): seed defaults into per-user workspace + fix Intelligence page stale log (#462)
* 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>
2026-04-09 22:10:55 +05:30
..
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-04-04 02:59:31 -07:00
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00