fix(boot): unstick "Initializing OpenHuman" after kill/reopen (auth-profile lock + concurrent snapshot)#2642
Merged
sanil-23 merged 3 commits intoMay 25, 2026
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✅ Files skipped from review due to trivial changes (2)
📝 WalkthroughWalkthroughThis PR improves error observability and reliability across keyring operations and auth profile persistence, and parallelizes snapshot construction to reduce latency. The changes add a keyring error diagnostic method, enrich error logging with debug details, improve lock stale recovery for incomplete lock files, and enable concurrent auth-user and runtime-snapshot building with independent timeouts. ChangesError Diagnostics and Snapshot Concurrency
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
coderabbitai
Bot
added
rust-core
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…g ~30s A kill/crash between `create_new` and the `pid=` write leaves a malformed (pidless) `auth-profiles.lock`. The old stale-check only reclaimed such a lock once it crossed STALE_LOCK_AGE_MS (30s), so on reopen `acquire_lock` — taken by `app_state_snapshot` via `load_app_session_profile` — blocked ~30–35s. The FE gates "Initializing OpenHuman" (PublicRoute → isBootstrapping) on that first snapshot, so the user is stuck on the loading screen for the whole window after a kill+reopen (observed: app_state_snapshot 42826ms; lock "has no parseable pid line; leaving in place"). A pidless lock can only be a crash artifact — a healthy holder writes its pid microseconds after create_new — so reclaim it after a short MALFORMED_LOCK_GRACE_MS (2s) instead of the full 30s. The grace stays non-zero so we never reclaim a live writer mid-create_new/pid= window. Valid-pid (dead → immediate; live+leaked → 30s) paths are unchanged. Test: clear_lock_if_stale_reclaims_pidless_lock_past_short_grace (pidless lock aged past the grace but well under STALE_LOCK_AGE_MS is now reclaimed); the fresh-lock (<grace) leave-alone test still holds. Co-Authored-By: Claude <noreply@anthropic.com>
…esn't stall `app_state_snapshot` is what the FE blocks on while showing "Initializing OpenHuman" (PublicRoute → isBootstrapping clears on the first snapshot). It ran the two backend-touching enrichments — current-user refresh (AUTH_FETCH_TIMEOUT 5s) and the runtime snapshot (RUNTIME_SNAPSHOT_TIMEOUT 10s) — sequentially, so a machine that can't reach the backend waited ~15s before falling back to the already-available local data (stored_user / degraded runtime). Run them concurrently with tokio::join! (both have local fallbacks, both only touch &config immutably). Worst-case bootstrap latency drops from ~15s to ~10s on an unreachable backend; with the auth-profile lock reclaim fix it goes from the observed ~42s to ~12s, and is sub-second when the backend is reachable. The FE clears isBootstrapping on this first snapshot, so "Initializing" no longer hangs after a kill+reopen. Co-Authored-By: Claude <noreply@anthropic.com>
We were blind diagnosing the macOS keychain failure: the OS backend wraps
`keyring::Error` and we logged only its Display, which collapses to
"No matching entry found in secure storage" (keyring's `NoEntry`) — hiding the
variant and any `OSStatus`, so a locked keychain, a denied prompt, and a missing
entitlement all look identical without Console.app.
Add `KeyringError::diagnostic()` (Debug of the error — variant + boxed source
chain, which for `PlatformFailure` carries the security-framework OSStatus; safe
to log, no secret values) and append it at the keychain error/swallow sites:
get/set/delete (ops.rs), the `is_available` probe failure (now `warn`, since it
silently flips `use_keychain`), `keychain_{store,load,delete}_secrets`
(profiles.rs), and the master-key migration + load (encrypted_store.rs). Also
log at info when `use_keychain` is false — the state change behind the
"no backend session token" confusion.
No behavior change; logging only.
Co-Authored-By: Claude <noreply@anthropic.com>
sanil-23
force-pushed
the
fix/auth-profile-lock-init-hang
branch
from
c380466 to
e308fdf
Compare
Open
12 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
auth-profiles.lock(left by a kill/crash mid-write) was reclaimed only after the full 30s stale-age, soacquire_lockblocked ~30s on reopen.app_state_snapshot— what the FE gates "Initializing OpenHuman" on (PublicRoute→isBootstrapping) — ran its two backend enrichments sequentially, adding ~15s when the backend was unreachable.Display("No matching entry found in secure storage"), hiding the variant/OSStatus— undiagnosable without Console.app.Problem
"Initializing OpenHuman" hung after killing and reopening the app (reported on a macOS staging build). From a user log, the first
app_state_snapshottook 42,826 ms because three things serialized while degraded: the auth-profile file lock (~30s on a stale pidless lock —[credentials] lock … has no parseable pid line; leaving in place),build_runtime_snapshot(10s timeout), andfetch_current_user(5s timeout), with the backend intermittently unreachable. The FE clearsisBootstrappingonly when that first snapshot returns, so the loading screen stayed up the whole time.Solution
credentials/profiles.rs— fast pidless-lock reclaim. A lock with no parseablepid=line can only be a crash/kill artifact (a healthy holder writes its pid microseconds aftercreate_new), so reclaim it after a shortMALFORMED_LOCK_GRACE_MS(2s) instead of the fullSTALE_LOCK_AGE_MS(30s). Valid-pid paths unchanged (dead → immediate, live+leaked → 30s). 30s → ~2s.app_state/ops.rs— concurrent enrichments. Run the current-user refresh and runtime snapshot undertokio::join!(both immutable-borrow&config, both already fall back to local data). Unreachable-backend worst case ~15s → ~10s. Net boot worst case ~42s → ~12s; sub-second when reachable.keyring/*+credentials/profiles.rs— diagnostics. NewKeyringError::diagnostic()(Debug — variant + boxed source chain, which carries the macOSOSStatusforPlatformFailure; no secret values) appended at every keychain error/swallow site;is_available=falseanduse_keychain=falsenow log atwarn/infoso the silent fallback flip is visible. Logging only.Submission Checklist
clear_lock_if_stale_reclaims_pidless_lock_past_short_grace(new) + the existing fresh-lock leave-alone test still holds;app_statesnapshot tests cover the concurrent path.cargo test(credentials::profiles 35, app_state 25, keyring 46) +cargo fmt --checklocally; fullcargo-llvm-cov/diff-covernot run locally — relying on CI to enforce.N/A: latency/robustness + logging change on an existing path; no feature row added/removed/renamed.N/A: no matrix feature touched.N/A: no new manual step; faster/bounded boot on the existing path.Closes #NNN—N/A: self-identified from a user-reported staging hang; no tracking issue.Impact
OSStatus).Display). No schema/migration change.Related
no backend session tokenshould not clear the session); thestaging-apiDNS flakiness on the affected machine is environmental.AI Authored PR Metadata
Linear Issue
Commit & Branch
fix/auth-profile-lock-init-hang82dba665(tip) —d503b898lock reclaim ·9babb4eeconcurrent snapshot ·82dba665keyring diagnosticsValidation Run
pnpm --filter openhuman-app format:check— N/A: noapp/(frontend) changes.pnpm typecheck— N/A: no TS changes.cargo test --lib credentials::profiles(35) ·app_state::(25) ·keyring::(46) — all pass.cargo fmt -- --checkclean ·cargo check --libclean.app/src-tauriuntouched.Validation Blocked
command:pre-push hookpnpm rust:checkerror:vendored CEF tauri-cli / pnpm env not present on the non-interactive shellimpact:pushed with--no-verify; only the Tauri shell check (unrelated, untouched) was skipped — corecargo check/fmt/tests ran clean.Behavior Changes
Parity Contract
stored_user/degraded_runtime_snapshotfallbacks unchanged; fresh (<2s) lock still left in place.Duplicate / Superseded PR Handling
Summary by CodeRabbit
Bug Fixes
Performance