Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix feat: add gateway.systemEvents.recoveryNotice config knob to suppress recovery prompt for customer-facing bots [1 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#72043•Fetched 2026-04-27 05:35:40
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
MaxK000MaxK000
Participants
MaxK000MaxK000
Timeline (top)
cross-referenced ×1

After a whole-file last-known-good config recovery, the Gateway pushes Gateway recovered automatically after a failed config change and restored the last known good configuration. into the next agent turn (as a System: prefix via enqueueSystemEvent) AND delivers it out-of-band on the originating channel. This is appropriate for an internal/owner agent — the model needs to know not to blindly rewrite the restored config — but it leaks technical wording into customer-facing personas.

Root Cause

After a whole-file last-known-good config recovery, the Gateway pushes Gateway recovered automatically after a failed config change and restored the last known good configuration. into the next agent turn (as a System: prefix via enqueueSystemEvent) AND delivers it out-of-band on the originating channel. This is appropriate for an internal/owner agent — the model needs to know not to blindly rewrite the restored config — but it leaks technical wording into customer-facing personas.

Fix Action

Fix / Workaround

  • #71289 narrowed when whole-file recovery triggers (plugin-local issues no longer roll back the whole file), but not what the recovery notice does once it does trigger.
  • #49579 (open) hardcodes a regex filter for one specific WhatsApp banner — useful but doesn't generalize; every new banner needs another patch.
  • #39307 (open) asks for the opposite — more user-visible mid-thread context resets. A general operator-controlled knob accommodates both audiences without forcing one default.
RAW_BUFFERClick to expand / collapse

Summary

After a whole-file last-known-good config recovery, the Gateway pushes Gateway recovered automatically after a failed config change and restored the last known good configuration. into the next agent turn (as a System: prefix via enqueueSystemEvent) AND delivers it out-of-band on the originating channel. This is appropriate for an internal/owner agent — the model needs to know not to blindly rewrite the restored config — but it leaks technical wording into customer-facing personas.

Observed

A drum-school Telegram bot (Spanish-speaking receptionist persona) received a /start from a tester right after a routine config-recovery. The agent's reply included verbatim:

"Привет! Да, всё работает — восстановился после сбоя конфига. Готов к работе 🥁 Если тестируешь флоу..."

The model broke persona, switched to the language of the recovery notice, and exposed gateway internals. The transcript shows the recovery notice was prepended to the user's /start message in a single user-role block, so the model had no way to distinguish operator metadata from user content.

Why a config knob

  • #71289 narrowed when whole-file recovery triggers (plugin-local issues no longer roll back the whole file), but not what the recovery notice does once it does trigger.
  • #49579 (open) hardcodes a regex filter for one specific WhatsApp banner — useful but doesn't generalize; every new banner needs another patch.
  • #39307 (open) asks for the opposite — more user-visible mid-thread context resets. A general operator-controlled knob accommodates both audiences without forcing one default.

Proposal

Add gateway.systemEvents.recoveryNotice:

ModePrompt prefixOut-of-band channelLog entry
"user" (default — current behavior)yesyesexisting summary log only
"log"nonosingle gateway/restart-sentinel info line
"off"nonono

Restart continuations (payload.continuation for restart-from-tool flows) and the recovery itself unaffected — the knob only controls the user-facing notice text on the two surfaces above.

Implementation sketch

  • New gateway.systemEvents block in zod-schema.ts and types.gateway.ts (one field today, room for future event-class knobs)
  • Read in loadRestartSentinelStartupTask (server-restart-sentinel.ts); gate enqueueSystemEvent / enqueueRestartSentinelWake and the deliverRestartSentinelNotice outbound call
  • Three unit tests in server-restart-sentinel.test.ts (one per mode)
  • Operator paragraph in docs/gateway/configuration.md
  • Changelog entry under ### Changes

Estimated diff: ~80 lines net. PR ready to send if the direction is acceptable; happy to adjust scope first if maintainers prefer a narrower fix or a different schema location.

extent analysis

TL;DR

Add a gateway.systemEvents.recoveryNotice configuration option to control the visibility of recovery notices in user-facing interfaces.

Guidance

  • Introduce a new configuration option gateway.systemEvents.recoveryNotice with modes "user", "log", and "off" to control the recovery notice behavior.
  • Update the loadRestartSentinelStartupTask function to read the new configuration option and gate the enqueueSystemEvent and deliverRestartSentinelNotice calls accordingly.
  • Add unit tests to cover the different modes of the gateway.systemEvents.recoveryNotice option.
  • Document the new configuration option in the docs/gateway/configuration.md file.

Example

// zod-schema.ts
import { z } from 'zod';

const gatewaySystemEventsSchema = z.object({
  recoveryNotice: z.enum(['user', 'log', 'off']),
});

// server-restart-sentinel.ts
if (config.gateway.systemEvents.recoveryNotice === 'user') {
  enqueueSystemEvent('Gateway recovered automatically after a failed config change and restored the last known good configuration.');
}

Notes

The proposed solution requires updating the schema, loading the new configuration option, and modifying the restart sentinel logic. The estimated diff is ~80 lines net.

Recommendation

Apply the proposed workaround by adding the gateway.systemEvents.recoveryNotice configuration option to control the visibility of recovery notices. This approach provides a flexible solution that accommodates different use cases and allows operators to choose the desired behavior.

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…
#api#ssr#container setup#orchestration issue#cache issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix feat: add gateway.systemEvents.recoveryNotice config knob to suppress recovery prompt for customer-facing bots [1 participants]