Slow profile snapshot triggers fallback before backend succeeds #2156

Summary

The frontend times out openhuman.app_state_snapshot after 30 seconds and sends users to the fallback even when the backend would succeed around 35–40 seconds.

Problem

The Almost there! fallback is the right recovery path for real profile-build failures, but it is currently triggered for users whose openhuman.app_state_snapshot call is only slightly slower than the 30-second frontend timeout.

Observed log example:

Core RPC openhuman.app_state_snapshot timed out after 30000ms

Meanwhile, successful backend snapshot calls took 32665ms, 35715ms, and 37825ms. This means users can be shown a failure-like fallback even though the operation would have succeeded if the frontend waited a bit longer or staged loading more gracefully.

Impact: users think login/profile build is broken when the system is actually still working.

Steps to reproduce:

1. Launch/login on a machine where openhuman.app_state_snapshot takes longer than 30 seconds but eventually succeeds.
2. Observe frontend core-state timeout at 30 seconds.
3. Observe user moved to the Almost there! fallback path.
4. Observe backend snapshot eventually completes successfully.

Solution (optional)

Either raise the frontend timeout for this first-launch/profile-build path or add staged loading: show still working… progress and keep waiting when the backend is slow but alive. Reserve the failure-like fallback for actual errors or a longer bounded timeout.

Acceptance criteria

• False fallback reduced — Users are not sent to the Almost there! fallback solely because snapshot needed 35–40 seconds on first launch.
• Timeout policy updated — The frontend timeout for first-launch/profile snapshot is increased, staged, or made adaptive with clear rationale.
• Progress UI added — Slow profile build shows a still working… style state instead of looking like a failure immediately at 30 seconds.
• Failure remains bounded — Real failures still reach a fallback/recovery path after a documented maximum wait.
• Backend alive detection — If possible, UI distinguishes slow-but-alive snapshot work from dead/unreachable core RPC.
• Regression safety — Tests cover slow-success, timeout, and real-failure paths for post-login profile build.
• Diff coverage ≥ 80% — the fix PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/coverage.yml).

Related

• Snapshot performance issue.