Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: Improving UX for Gateway Restart Confirmation on Dreaming Toggle [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63804•Fetched 2026-04-10 03:41:52
View on GitHub
Comments
2
Participants
2
Timeline
4
Reactions
0
Author
bbddbb1bbddbb1
Participants
ArtyomkunArtyomkunbbddbb1bbddbb1
Timeline (top)
commented ×2cross-referenced ×1labeled ×1

Add an explicit confirmation flow before any Dreaming toggle action that restarts the Gateway.

Error Message

On the Dreaming page, toggling Dreaming mode currently triggers a Gateway restart without clear user confirmation in the interaction moment. This is insufficient because users do not get an explicit warning about temporary interruption risk before initiating a system-level action. As a result, users can accidentally cause downtime, lose context, or misinterpret the brief disconnection as an error.

Root Cause

On the Dreaming page, toggling Dreaming mode currently triggers a Gateway restart without clear user confirmation in the interaction moment. This is insufficient because users do not get an explicit warning about temporary interruption risk before initiating a system-level action. As a result, users can accidentally cause downtime, lose context, or misinterpret the brief disconnection as an error.

Fix Action

Fixed

PR fix notes

PR #63807: feat(control-ui): add gateway restart confirmation dialog and related…

Description (problem / solution / changelog)

Summary

  • Problem: Toggling Dreaming mode could trigger a gateway restart-impacting config update without an explicit confirmation step in the click flow.
  • Why it matters: Users can unintentionally cause temporary service interruption (chat/channels/automations) and interpret the restart/disconnect as a failure.
  • What changed: Added a confirmation modal with warning copy, Cancel and Confirm Restart actions, and Restarting… loading feedback; wired toggle to run only after explicit confirm.
  • What did NOT change (scope boundary): No backend gateway restart implementation changes, no protocol/API contract changes, no unrelated UI refactors.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #63804
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: The Dreaming toggle path executed mode update logic immediately, with no user confirmation gate before restart-impacting behavior.
  • Missing detection / guardrail: No UX contract/test asserting confirm-before-execution for restart-sensitive actions.
  • Contributing context (if known): Existing toggle was optimized for direct state change, not restart-risk communication.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: ui/src/ui/navigation.browser.test.ts
  • Scenario the test should lock in: Clicking Dreaming toggle does not send config patch until Confirm Restart is pressed; after confirm, patch is sent.
  • Why this is the smallest reliable guardrail: It validates real rendered UI interaction + event wiring + client request side effects in one focused test.
  • Existing test that already covers this (if any): None for this exact confirmation gate.
  • If no new test is added, why not: N/A (new test added).

User-visible / Behavior Changes

  • Dreaming toggle now opens a warning confirmation dialog before applying restart-impacting change.
  • Dialog presents Cancel and Confirm Restart actions.
  • Confirm action shows Restarting… loading state while request is in-flight.
  • No immediate silent restart-triggering action on first click.

Diagram (if applicable)

Before:
[user clicks dreaming toggle] -> [mode update request sent immediately] -> [gateway restart side effects]

After:
[user clicks dreaming toggle] -> [confirmation dialog shown]
  -> [Cancel] -> [no request]
  -> [Confirm Restart] -> [request sent + Restarting… feedback] -> [status refresh]

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: Linux
  • Runtime/container: Node 22+
  • Model/provider: N/A
  • Integration/channel (if any): Control UI Dreaming tab
  • Relevant config (redacted): Dreaming enabled with memory plugin config path available

Steps

  1. Open Control UI Dreaming page with Dreaming currently on.
  2. Click the Dreaming phase toggle.
  3. Observe modal; click Cancel, then click toggle again and choose Confirm Restart.

Expected

  • First click only opens confirmation.
  • Cancel performs no mode update request.
  • Confirm Restart performs update and shows Restarting… feedback.

Actual

  • Matches expected behavior after this change.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant) <img width="1916" height="945" alt="image" src="https://github.com/user-attachments/assets/3c41067f-473d-464c-8825-5af1bedc8045" />

Human Verification (required)

  • Verified scenarios:
    • Toggle interception opens confirmation modal.
    • Cancel path does not execute update.
    • Confirm path executes update and shows loading state.
  • Edge cases checked:
    • Re-click while loading is blocked.
    • Existing status/error surfaces remain intact.
  • What you did not verify:
    • Full cross-locale copy review for all translated locale bundles.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: Modal could accidentally block toggle flow if state is not cleared correctly.
    • Mitigation: Explicit open/close/pending state handling and browser test coverage for cancel/confirm behavior.
  • Risk: Users may still perceive restart as failure if warning copy is unclear.
    • Mitigation: High-visibility warning copy with explicit restart/interruption language and in-flight Restarting… feedback. … state management

Changed files

  • ui/src/i18n/locales/en.ts (modified, +8/-0)
  • ui/src/ui/app-render.ts (modified, +40/-7)
  • ui/src/ui/app-view-state.ts (modified, +3/-0)
  • ui/src/ui/app.ts (modified, +3/-0)
  • ui/src/ui/navigation.browser.test.ts (modified, +181/-1)
  • ui/src/ui/views/dreaming-restart-confirmation.ts (added, +43/-0)
RAW_BUFFERClick to expand / collapse

Summary

Add an explicit confirmation flow before any Dreaming toggle action that restarts the Gateway.

Problem to solve

On the Dreaming page, toggling Dreaming mode currently triggers a Gateway restart without clear user confirmation in the interaction moment. This is insufficient because users do not get an explicit warning about temporary interruption risk before initiating a system-level action. As a result, users can accidentally cause downtime, lose context, or misinterpret the brief disconnection as an error.

Proposed solution

Implement a confirmation-first UX for Dreaming mode changes that can trigger restart behavior:

Intercept toggle clicks before sending restart-triggering updates. Show a high-visibility confirmation dialog with clear warning copy: action will restart the Gateway temporary interruption to chats/automations/channels may occur Provide two explicit actions: Cancel (abort, no restart call) Confirm Restart (warning style action) After confirmation, show immediate processing feedback: Restarting… button/loading state (or equivalent user-visible progress signal) Only execute the underlying restart-triggering config update after explicit confirmation.

Alternatives considered

Toast-only warning after click: too late; restart intent already committed. Inline helper text near toggle: low salience, easy to miss during routine use. Double-click or long-press to confirm: non-standard, discoverability and accessibility concerns. Separate settings page for restart actions: adds friction and context switching for a frequent control.

Impact

Affected users/systems/channels: Users managing Dreaming mode in Control UI; downstream impact on active chat flows, cron/automation execution windows, and connected channels during restart windows. Severity: Moderate to high (can disrupt active workflows; can feel like a failure condition). Frequency: Always reproducible whenever Dreaming toggle changes restart-sensitive state. Consequence: Unexpected interruptions, temporary disconnects, confusion, avoidable manual retries, and possible loss of in-progress user context.

Evidence/examples

Current behavior: toggle action initiates restart-triggering update without explicit confirmation in the click path.

Additional information

No response

extent analysis

TL;DR

Implement a confirmation dialog with clear warning copy and explicit actions before triggering a Gateway restart when toggling Dreaming mode.

Guidance

  • Intercept toggle clicks to show a high-visibility confirmation dialog with warning copy about potential temporary interruption risks.
  • Provide two explicit actions in the dialog: Cancel and Confirm Restart, with the latter styled as a warning action.
  • Display immediate processing feedback, such as a "Restarting…" button or loading state, after confirmation.
  • Only execute the underlying restart-triggering config update after explicit user confirmation.

Example

// Pseudocode example of intercepting toggle clicks and showing a confirmation dialog
toggleDreamingMode = () => {
  const confirmation = confirm('Restarting the Gateway will cause temporary interruptions. Confirm?');
  if (confirmation) {
    // Display processing feedback
    showRestartingFeedback();
    // Execute restart-triggering config update
    restartGateway();
  }
}

Notes

This solution focuses on adding an explicit confirmation flow to mitigate the risk of accidental Gateway restarts and temporary interruptions.

Recommendation

Apply the proposed solution of implementing a confirmation-first UX for Dreaming mode changes to ensure users are aware of the potential risks before initiating a system-level action.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#embedding generation#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING