openclaw - ✅(Solved) Fix [Bug]: Gateway does not load model configuration from openclaw.json on restart [2 pull requests, 3 comments, 3 participants]

TheColorPlum · 2026-03-13T03:33:35Z

[openclaw] The OpenClaw gateway is failing to apply model configuration changes from ~/.openclaw/openclaw.json after a service restart. It continues to use the… The OpenClaw gateway is failing to apply model configuration changes from ~/.openclaw/openclaw.json after a service restart. It continues to use the model that was active before the configuration file was changed, effectively ignoring the updated settings on disk. # PR #2: OpenClaw 紧急未修复 - Repository: haoruilee/openclaw - Author: haoruilee - State: closed | merged: False - Link: https://github.com/haoruilee/openclaw/pull/2 ## Description (problem / solution / changelog) ## Summary Describe the problem and fix in 2–5 bullets: - Problem: The Gateway crashes with an unhandled promise rejection when the Discord API returns a 503 error, as `response.json()` is called without checking `response.ok`. - Why it matters: This causes the entire gateway process to exit, leading to a complete service interruption for all connected Discord channels for several minutes. - What changed: Added a check for `response.ok` before attempting to parse the JSON response. Errors are now emitted via `this.emitter.emit("error")` and `this.handleReconnectionAttempt()` is called to trigger a graceful reconnection attempt, preventing a full process crash. Updated tests to cover the 503 error path. - What did NOT change (scope boundary): Other identified issues (#44544, #44611, #44562, #44549) were either already fixed, determined not to be code bugs, or required a dedicated test environment for safe implementation and are not part of this PR. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #44529 - Related # ## User-visible / Behavior Changes The gateway will no longer crash when the Discord API returns a 503 error during client registration. Instead, it will log the error and attempt to reconnect gracefully. ## 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: ## Repro + Verification ### Environment - OS: Linux (typical Node.js environment) - Runtime/container: Node.js - Model/provider: N/A - Integration/channel (if any): Discord - Relevant config (redacted): N/A ### Steps 1. Configure OpenClaw Gateway with a Discord integration. 2. During the `GatewayPlugin.registerClient()` call (e.g., when the health monitor triggers a Discord bot reconnection), simulate a Discord API returning a 503 HTTP status code with a non-JSON body. 3. Observe the gateway process. ### Expected - The gateway logs an error about the Discord 503 response. - The gateway attempts to reconnect to Discord without crashing the entire Node.js process. ### Actual - The gateway process crashes with an unhandled promise rejection. ## Evidence - [x] Failing test/log before + passing after (New test `should handle 503 response gracefully without crashing` added to `provider.proxy.test.ts` which now passes.) - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: Added and passed a new unit test specifically for the 503 error case in `provider.proxy.test.ts`, ensuring the `response.ok` check and error handling logic are correctly implemented. - Edge cases checked: Specifically addressed the case where `response.json()` would throw an error on a non-2xx response. - What you did **not** verify: Did not verify in a live production environment with an actual Discord 503 error. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert this PR. - Files/config to restore: N/A - Known bad symptoms reviewers should watch for: Gateway still crashing on Discord 503, or Discord reconnection issues. ## Risks and Mitigations - Risk: The error handling or reconnection logic might not fully cover all edge cases of Discord API errors. - Mitigation: The current fix addresses the immediate crash by preventing `response.json()` on bad responses and uses existing reconnection mechanisms. Further monitoring of Discord integration health is always recommended. <source me

openclaw2026-03-13 03:33:35

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#44611•Fetched 2026-04-08 00:44:34

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×3cross-referenced ×2labeled ×2referenced ×1

The OpenClaw gateway is failing to apply model configuration changes from ~/.openclaw/openclaw.json after a service restart. It continues to use the model that was active before the configuration file was changed, effectively ignoring the updated settings on disk.

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Steps to reproduce

Configure ~/.openclaw/openclaw.json to use a specific model as the primary, for example: "primary":
"google/gemini-2.5-pro".
Start the gateway service (sudo systemctl start clawdbot.service).
Connect to an agent and verify it is using the correct model.
Modify ~/.openclaw/openclaw.json to change the primary model, for example: "primary": "anthropic/claude-opus-4-5".
Restart the gateway service (sudo systemctl restart clawdbot.service).
Connect to an agent and check its active model.

Expected behavior

The agent's active model should be anthropic/claude-opus-4-5, as defined in the now-modified openclaw.json file.

Actual behavior

The agent's active model remains google/gemini-2.5-pro. The gateway appears to be using a cached or stale
configuration and is not reloading the file from disk on restart.

OpenClaw version

OpenClaw Version: 2026.3.7

Operating system

Linux

Install method

No response

Model

google/gemini-2.5-pro

Provider / routing chain

openclaw -> gateway -> gemini

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Troubleshooting Steps Performed

Verified file permissions and content of openclaw.json are correct.
Attempted restarts using file-watching (by saving the file), openclaw gateway restart, and sudo systemctl restart
clawdbot.service.
A deep diagnostic (openclaw status --deep) revealed a conflicting and broken user-level systemd service, which has
since been removed.
The issue persists even with a single, clean system-level service, indicating the problem is not with the service
management environment but likely within the gateway's configuration loading logic itself.

extent analysis

Fix Plan

To resolve the issue of the OpenClaw gateway not applying model configuration changes from ~/.openclaw/openclaw.json after a service restart, we need to ensure that the configuration is reloaded properly.

Here are the steps to fix the issue:

Check Configuration Loading Logic: Review the OpenClaw gateway's configuration loading logic to ensure it reloads the configuration file on restart.
Implement Configuration Reload: Modify the gateway to reload the configuration file from disk on restart. This can be achieved by:
- Adding a configuration reload mechanism in the gateway's startup script.
- Using a file watcher to detect changes to the configuration file and reload it accordingly.
Example Code: In Python, you can use the watchdog library to watch for changes to the configuration file and reload it:

from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler

class ConfigReloadHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path == '~/.openclaw/openclaw.json': # Reload configuration logic here print("Configuration reloaded")

if name == "main": event_handler = ConfigReloadHandler() observer = Observer() observer.schedule(event_handler, path='~/.openclaw/', recursive=False) observer.start()

* **Verify Configuration Reload**: After implementing the configuration reload mechanism, verify that the gateway reloads the configuration file correctly by modifying the `openclaw.json` file and restarting the service.

### Verification
To verify that the fix worked:
* Restart the gateway service.
* Connect to an agent and check its active model.
* The agent's active model should match the one defined in the modified `openclaw.json` file.

### Extra Tips
* Ensure that the configuration file permissions and content are correct.
* Use a deep diagnostic tool like `openclaw status --deep` to identify any conflicting services or issues.
* Consider implementing a backup and restore mechanism for the configuration file to prevent data loss.

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?

FAQ

Expected behavior

The agent's active model should be anthropic/claude-opus-4-5, as defined in the now-modified openclaw.json file.

#api #ssr #installation #tensor shape #autograd error #vector store #embedding generation #cache error #pipeline error #runtime error

Still need to ship something?

×6

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

openclaw - ✅(Solved) Fix [Bug]: Gateway does not load model configuration from openclaw.json on restart [2 pull requests, 3 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fixed

PR fix notes

PR #2: OpenClaw 紧急未修复

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #51348: fix: clear session model override when it matches config default

Description (problem / solution / changelog)

Root Cause

Solution

Changes

Testing

Impact

Changed files

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING