fix(ui): suppress disconnected banner during onboarding

[lklimek]

Why this PR exists

• Problem: On a fresh launch, the onboarding Welcome screen shows a red "Disconnected — check your internet connection" error banner before the user has done anything — no wallet exists yet and nothing has attempted to sync.
• What breaks without it: OverallConnectionState::Disconnected is ConnectionStatus's default atomic state. On cold start there is no wallet and SPV has not been asked to connect, so the state simply hasn't left its initial value yet — the reconciler reads "hasn't started" as "can't connect" and raises an alarming, actionable-looking error banner the user cannot do anything about (there's nothing to retry — nothing was ever attempted).
• Blocking relationship: stacked on feat(ui): redesign welcome-screen experience-level selector as cards #903 (welcome-screen card redesign) — same screen, no file overlap, based on it for a clean history. Also assumes fix(wallet): surface DAPI endpoint exhaustion #904 (DAPI endpoint exhaustion) lands before this merges, per request, though the two touch unrelated files and neither depends on the other's code.

What was done

• Threaded a new onboarding_active: bool param into ConnectionBanner::update (src/app/reconcilers.rs), fed from the existing AppState.show_welcome_screen signal at the call site in src/app.rs.
• When onboarding_active && current_state == OverallConnectionState::Disconnected, the banner is suppressed: any existing handle is cleared, previous_state still advances (so state-change bookkeeping never desyncs), and no banner is set — mirrored on the existing spv_overlaying suppression branch just above it.
• Every other state (Connecting/Syncing/Error/Synced) is completely unaffected, on or off the onboarding screen. Once onboarding completes and SPV starts, the normal banner machine resumes immediately with no lingering suppression.
• src/ui/welcome_screen.rs rendering/layout was not touched — this is a global-banner-reconciler fix, not a screen-local one.

Testing

• New kittest regression welcome_screen_suppresses_disconnected_banner: builds a fresh AppState (cold start naturally begins Disconnected), asserts the welcome screen is showing and the "check your internet connection" text is absent. Confirmed RED before the fix (banner present, test failed) and GREEN after.
• cargo clippy --all-features --all-targets -- -D warnings — clean.
• cargo +nightly fmt --all, cargo fmt --all — clean.

Breaking changes

None.

Checklist

• Conventional commits
• CHANGELOG.md updated (Unreleased → Fixed)
• docs/user-stories.md — not touched; this is a bug fix to banner display, not a new feature (consistent with fix(wallet): surface DAPI endpoint exhaustion #904's precedent for this repo's convention)

Attribution

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Warning

Review limit reached

@lklimek, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 55 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: de1b9e05-733d-4dd1-8fa6-483d96b3b09b

📥 Commits

Reviewing files that changed from the base of the PR and between 04b8212 and 9e65baf.

📒 Files selected for processing (4)

• CHANGELOG.md
• src/app.rs
• src/app/reconcilers.rs
• tests/kittest/welcome_screen.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/onboarding-disconnected-banner

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Ready for review — 26 ahead in queue (commit 9e65baf)
Queue position: 27/29

[Claudius-Maginificent]

@/tmp/pr907-comment.md

[thepastaclaw]

Preliminary review — Codex only

The PR correctly suppresses the misleading cold-start Disconnected banner and fixes the prior bug that hid a persistent Disconnected state after onboarding. However, the suppression branch leaves a previously recorded non-Disconnected state intact, so a Syncing → Disconnected → Syncing transition during onboarding clears the Syncing banner and prevents it from returning. A focused verifier regression reproduced the failure, and resetting previous_state to None fixed both this sequence and the PR's existing post-onboarding regression test.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/app/reconcilers.rs`:
- [BLOCKING] src/app/reconcilers.rs:303-307: Clear stale previous state when suppressing Disconnected
  This branch clears the active banner without clearing previous_state. If a non-Disconnected state was previously reconciled, a temporary DAPI outage can produce Disconnected during onboarding, clear that state's banner here, and then return to the recorded state. The unchanged-state fast path at lines 271-273 then returns without restoring the banner. This is reachable when the feature-gated MCP server starts SPV through the AppContext shared with the GUI while onboarding is still open; ConnectionStatus::refresh_state also explicitly maps temporary DAPI unavailability to Disconnected. A focused verifier test reproduced Syncing → Disconnected → Syncing leaving handle as None. Set previous_state to None during suppression so every state after the suppressed interval is reconciled; this also preserves the new behavior that shows a persistent Disconnected state immediately after onboarding ends.

[thepastaclaw]

Preliminary review — Codex only

The latest delta fixes prior finding 5b07736d88d2 by invalidating previous_state during onboarding suppression and adding a regression test for recurring states. However, the new 120-second limit reintroduces the PR's original misleading Disconnected banner while the Welcome screen is still legitimately active, contradicting both the authoritative onboarding signal and the changelog promise that suppression lasts until onboarding finishes. No other in-scope findings were confirmed.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/app/reconcilers.rs`:
- [BLOCKING] src/app/reconcilers.rs:298-300: Suppress Disconnected for the entire onboarding session
  The elapsed-time condition stops suppression 120 seconds after ConnectionBanner is constructed even when onboarding_active remains true. The Welcome screen has no automatic timeout and remains active until the user selects an onboarding path, so a user who spends more than two minutes reading or deciding will see the red "Disconnected — check your internet connection" banner while the connection state is still its untouched cold-start default and no sync has been attempted. This directly restores the behavior the PR is intended to remove and contradicts the changelog statement that the banner stays hidden until onboarding finishes. A persistence failure does not justify this timer: selecting a path sets show_welcome_screen to false synchronously through AppAction::OnboardingComplete even if update_onboarding_completed fails, with any persistence problem affecting only a later launch. Use onboarding_active as the suppression lifetime and remove the timer field, constant, and expiry test.

[thepastaclaw]

Preliminary review — Codex only

At exact HEAD a5f374d, the prior blocking finding remains valid: the hard-coded 120-second limit can expose the misleading Disconnected banner while onboarding is still legitimately active. The latest delta leaves the reconciler unchanged and restores only immediate-start kittest coverage, while the current unit test explicitly codifies the incorrect post-timeout behavior; no additional in-scope findings were confirmed.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

[thepastaclaw]

Preliminary review — Codex only

Carried forward: the prior blocking finding remains valid because the 120-second limit can expose the misleading Disconnected banner while onboarding is still active. Latest delta: the v1.0-dev merge does not modify the reconciler or fix this issue, and no new findings were confirmed.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

[Claudius-Maginificent]

Pushed a fix for the onboarding-suppression/CHANGELOG contradiction: the disconnected banner is now suppressed for the full Welcome/onboarding flow (no more 120s cap), matching the documented behavior, and lifts immediately once onboarding ends.

Commit: f7e1f4af

_{🤖 Co-authored by Claudius the Magnificent AI Agent}