fix(synology-chat): prevent restart loop in startAccount by druide67 · Pull Request #23074 · openclaw/openclaw

druide67 · 2026-02-22T00:17:07Z

Summary

Problem: The Synology Chat channel plugin enters a restart loop (exponential backoff, up to 10 attempts) immediately after starting
Root cause: startAccount returns a synchronous { stop } object. The gateway wraps the return value in Promise.resolve(), which resolves immediately. The gateway interprets this as a crash and triggers auto-restart.
Fix: Replace the synchronous return with a Promise<void> that stays pending until ctx.abortSignal fires, keeping the channel alive until the gateway explicitly requests shutdown.

Change Type

Bug fix

Scope

Integrations (synology-chat extension only)

What Changed

extensions/synology-chat/src/channel.ts: gateway.startAccount now returns a pending Promise that resolves on abortSignal, instead of a synchronous { stop } object

Security Impact

No security impact — only changes the lifecycle management of the channel plugin

Repro + Verification

Start OpenClaw with Synology Chat enabled
Before fix: gateway logs show auto-restart attempt 1/10, 2/10, etc. with exponential backoff
After fix: single startup log, no restart attempts

Human Verification

Tested on Synology DS923+ with DSM 7.2
Single startup, no restart loop in logs
Bot responds correctly to DMs
Clean shutdown on abortSignal

Compatibility

Backward compatible: yes
No config changes needed

🤖 Generated with Claude Code

Greptile Summary

Fixed restart loop in Synology Chat channel by returning a pending Promise from startAccount instead of a synchronous object. The gateway wraps all returns in Promise.resolve(), so the old synchronous { stop } return resolved immediately, triggering exponential backoff restarts.

Critical Issues:

Incomplete fix: disabled/unconfigured accounts (lines 213, 220) still return synchronous { stop: () => {} }, which will cause the same restart loop
Tests are now incorrect: they expect { stop: function } but the fix changes the return type to a pending Promise

What works:

Properly configured accounts now return a pending Promise that only resolves when abortSignal fires
Cleanup logic properly unregisters HTTP routes and removes event listeners
Fix aligns with the gateway's expectation that startAccount returns a Promise that stays pending while the channel runs

Confidence Score: 2/5

This PR has critical logical errors that will cause the same restart loop issue it claims to fix
The fix is incomplete and partially incorrect. While it correctly addresses the restart loop for properly configured accounts (lines 287-299), it fails to apply the same fix to disabled/unconfigured accounts (lines 213, 220), which still return the synchronous { stop: () => {} } that causes restart loops. Additionally, the tests are now incorrect and would fail to catch the incomplete fix since they still expect the old return type.
extensions/synology-chat/src/channel.ts (lines 213, 220 must return pending Promise), extensions/synology-chat/src/channel.test.ts (tests expect wrong return type)

_{Last reviewed commit: ded2228}

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}

greptile-apps

_{16 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-22T00:20:51Z

extensions/synology-chat/src/channel.ts

+        if (!account.enabled) {
+          log?.info?.(`Synology Chat account ${accountId} is disabled, skipping`);
+          return { stop: () => {} };
+        }


returning synchronous { stop: () => {} } will cause the same restart loop for disabled accounts

the gateway wraps all startAccount returns in Promise.resolve(), so returning { stop: () => {} } resolves immediately and triggers auto-restart logic (src/gateway/server-channels.ts:203-228)

Suggested change

if (!account.enabled) {

log?.info?.(`Synology Chat account ${accountId} is disabled, skipping`);

return { stop: () => {} };

}

log?.info?.(`Synology Chat account ${accountId} is disabled, skipping`);

return new Promise<void>(() => {});

}

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/synology-chat/src/channel.ts Line: 211-214 Comment: returning synchronous `{ stop: () => {} }` will cause the same restart loop for disabled accounts the gateway wraps all `startAccount` returns in `Promise.resolve()`, so returning `{ stop: () => {} }` resolves immediately and triggers auto-restart logic (src/gateway/server-channels.ts:203-228) ```suggestion log?.info?.(`Synology Chat account ${accountId} is disabled, skipping`); return new Promise<void>(() => {}); } ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-22T00:20:52Z

extensions/synology-chat/src/channel.ts

+        if (!account.token || !account.incomingUrl) {
+          log?.warn?.(
+            `Synology Chat account ${accountId} not fully configured (missing token or incomingUrl)`,
+          );
+          return { stop: () => {} };
+        }


same restart loop issue for unconfigured accounts

Suggested change

if (!account.token || !account.incomingUrl) {

log?.warn?.(

`Synology Chat account ${accountId} not fully configured (missing token or incomingUrl)`,

);

return { stop: () => {} };

}

log?.warn?.(

`Synology Chat account ${accountId} not fully configured (missing token or incomingUrl)`,

);

return new Promise<void>(() => {});

}

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/synology-chat/src/channel.ts Line: 216-221 Comment: same restart loop issue for unconfigured accounts ```suggestion log?.warn?.( `Synology Chat account ${accountId} not fully configured (missing token or incomingUrl)`, ); return new Promise<void>(() => {}); } ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-22T00:20:53Z

extensions/synology-chat/src/channel.test.ts

+        log: { info: vi.fn(), warn: vi.fn(), error: vi.fn() },
+      };
+      const result = await plugin.gateway.startAccount(ctx);
+      expect(typeof result.stop).toBe("function");


test expects { stop: function } but the fix changes this to return a pending Promise

after the fix, disabled accounts should return new Promise<void>(() => {}) (never-resolving promise), not { stop: () => {} }

update test to verify the return is a Promise that stays pending

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/synology-chat/src/channel.test.ts Line: 323 Comment: test expects `{ stop: function }` but the fix changes this to return a pending Promise after the fix, disabled accounts should return `new Promise<void>(() => {})` (never-resolving promise), not `{ stop: () => {} }` update test to verify the return is a Promise that stays pending How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-22T00:20:54Z

extensions/synology-chat/src/channel.test.ts

+        log: { info: vi.fn(), warn: vi.fn(), error: vi.fn() },
+      };
+      const result = await plugin.gateway.startAccount(ctx);
+      expect(typeof result.stop).toBe("function");


same issue - test expects { stop: function } but should expect a pending Promise

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/synology-chat/src/channel.test.ts Line: 336 Comment: same issue - test expects `{ stop: function }` but should expect a pending Promise How can I resolve this? If you propose a fix, please make it concise.

druide67 · 2026-02-24T12:07:31Z

Rebased on latest main and addressed all Greptile review comments:

Disabled/unconfigured accounts now return new Promise<void>(() => {}) (never-resolving) instead of { stop: () => {} }, preventing the restart loop triggered by Promise.resolve() in the gateway's startAccount wrapper.
Cleanup function now includes both activeRouteUnregisters.delete(routeKey) and ctx.abortSignal?.removeEventListener("abort", cleanup).
Tests updated: pending-promise race pattern for disabled/unconfigured accounts, AbortController for the stale-route deregistration test.

All 22 tests pass locally (vitest 4.0.18, 525ms).

druide67 · 2026-02-25T21:40:06Z

Friendly ping — this PR has been open for a few days now. CI is fully green, mergeable, and Greptile review comments have been addressed (see my previous comment). Would appreciate a maintainer review when you get a chance. Happy to address any feedback. Thanks!

startAccount must return a Promise that stays pending while the channel is running. The gateway wraps the return value in Promise.resolve(), and when it resolves, the gateway thinks the channel crashed and auto-restarts with exponential backoff (5s → 10s → 20s..., up to 10 attempts). Replace the synchronous { stop } return with a Promise<void> that resolves only when ctx.abortSignal fires, keeping the channel alive until shutdown. Tested on Synology DS923+ with DSM 7.2 — single startup, no restart loop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

startAccount returns `void | { stop: () => void }` — TypeScript requires a type guard before accessing .stop on the union type. Added proper checks in both integration and unit tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…ws compat Replace EventEmitter + process.nextTick with Readable stream for request body simulation. The process.nextTick approach caused the test to hang on Windows CI (120s timeout) because events were not reliably delivered to readBody() listeners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

@druide67

…hanks @druide67)

steipete · 2026-03-02T20:06:29Z

Landed via temp rebase onto main.

Gate: pnpm vitest run extensions/synology-chat/src/channel.test.ts extensions/synology-chat/src/channel.integration.test.ts --maxWorkers=1
Land commit: 36ddef7
Merge commit: b52561b

Thanks @druide67!

@druide67

) * fix(synology-chat): prevent restart loop in startAccount startAccount must return a Promise that stays pending while the channel is running. The gateway wraps the return value in Promise.resolve(), and when it resolves, the gateway thinks the channel crashed and auto-restarts with exponential backoff (5s → 10s → 20s..., up to 10 attempts). Replace the synchronous { stop } return with a Promise<void> that resolves only when ctx.abortSignal fires, keeping the channel alive until shutdown. Tested on Synology DS923+ with DSM 7.2 — single startup, no restart loop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): add type guards for startAccount return value startAccount returns `void | { stop: () => void }` — TypeScript requires a type guard before accessing .stop on the union type. Added proper checks in both integration and unit tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): use Readable stream in integration test for Windows compat Replace EventEmitter + process.nextTick with Readable stream for request body simulation. The process.nextTick approach caused the test to hang on Windows CI (120s timeout) because events were not reliably delivered to readBody() listeners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: stabilize synology gateway account lifecycle (openclaw#23074) (thanks @druide67) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Peter Steinberger <steipete@gmail.com>

@druide67

) * fix(synology-chat): prevent restart loop in startAccount startAccount must return a Promise that stays pending while the channel is running. The gateway wraps the return value in Promise.resolve(), and when it resolves, the gateway thinks the channel crashed and auto-restarts with exponential backoff (5s → 10s → 20s..., up to 10 attempts). Replace the synchronous { stop } return with a Promise<void> that resolves only when ctx.abortSignal fires, keeping the channel alive until shutdown. Tested on Synology DS923+ with DSM 7.2 — single startup, no restart loop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): add type guards for startAccount return value startAccount returns `void | { stop: () => void }` — TypeScript requires a type guard before accessing .stop on the union type. Added proper checks in both integration and unit tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): use Readable stream in integration test for Windows compat Replace EventEmitter + process.nextTick with Readable stream for request body simulation. The process.nextTick approach caused the test to hang on Windows CI (120s timeout) because events were not reliably delivered to readBody() listeners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: stabilize synology gateway account lifecycle (openclaw#23074) (thanks @druide67) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Peter Steinberger <steipete@gmail.com>

@druide67

) * fix(synology-chat): prevent restart loop in startAccount startAccount must return a Promise that stays pending while the channel is running. The gateway wraps the return value in Promise.resolve(), and when it resolves, the gateway thinks the channel crashed and auto-restarts with exponential backoff (5s → 10s → 20s..., up to 10 attempts). Replace the synchronous { stop } return with a Promise<void> that resolves only when ctx.abortSignal fires, keeping the channel alive until shutdown. Tested on Synology DS923+ with DSM 7.2 — single startup, no restart loop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): add type guards for startAccount return value startAccount returns `void | { stop: () => void }` — TypeScript requires a type guard before accessing .stop on the union type. Added proper checks in both integration and unit tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(synology-chat): use Readable stream in integration test for Windows compat Replace EventEmitter + process.nextTick with Readable stream for request body simulation. The process.nextTick approach caused the test to hang on Windows CI (120s timeout) because events were not reliably delivered to readBody() listeners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: stabilize synology gateway account lifecycle (openclaw#23074) (thanks @druide67) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Peter Steinberger <steipete@gmail.com>

@druide67

) * fix(synology-chat): prevent restart loop in startAccount startAccount must return a Promise that stays pending while the channel is running. The gateway wraps the return value in Promise.resolve(), and when it resolves, the gateway thinks the channel crashed and auto-restarts with exponential backoff (5s → 10s → 20s..., up to 10 attempts). Replace the synchronous { stop } return with a Promise<void> that resolves only when ctx.abortSignal fires, keeping the channel alive until shutdown. Tested on Synology DS923+ with DSM 7.2 — single startup, no restart loop. * fix(synology-chat): add type guards for startAccount return value startAccount returns `void | { stop: () => void }` — TypeScript requires a type guard before accessing .stop on the union type. Added proper checks in both integration and unit tests. * fix(synology-chat): use Readable stream in integration test for Windows compat Replace EventEmitter + process.nextTick with Readable stream for request body simulation. The process.nextTick approach caused the test to hang on Windows CI (120s timeout) because events were not reliably delivered to readBody() listeners. * fix: stabilize synology gateway account lifecycle (openclaw#23074) (thanks @druide67) --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

openclaw-barnacle bot added the size: XL label Feb 22, 2026

greptile-apps bot reviewed Feb 22, 2026

View reviewed changes

druide67 force-pushed the fix/synology-chat-restart-loop branch from ded2228 to 102b919 Compare February 23, 2026 06:33

openclaw-barnacle bot added size: XS and removed size: XL labels Feb 23, 2026

druide67 force-pushed the fix/synology-chat-restart-loop branch 2 times, most recently from 07442e9 to 005e1a2 Compare February 24, 2026 12:07

openclaw-barnacle bot added size: S and removed size: XS labels Feb 24, 2026

druide67 force-pushed the fix/synology-chat-restart-loop branch from 005e1a2 to ae2d828 Compare February 24, 2026 12:20

druide67 force-pushed the fix/synology-chat-restart-loop branch 3 times, most recently from 067d31c to 65dc370 Compare March 2, 2026 18:28

steipete mentioned this pull request Mar 2, 2026

fix(synology-chat): fix outbound delivery, health monitor restart loop, and native commands #24274

Closed

druide67 and others added 4 commits March 2, 2026 20:04

fix: stabilize synology gateway account lifecycle (openclaw#23074) (t…

36ddef7

…hanks @druide67)

steipete force-pushed the fix/synology-chat-restart-loop branch from 65dc370 to 36ddef7 Compare March 2, 2026 20:06

steipete merged commit b52561b into openclaw:main Mar 2, 2026
9 checks passed

github-actions bot mentioned this pull request Mar 2, 2026

📡 Upstream Digest — 2026-03-02 20:27 UTC curtismercier/openclaw-mods#166

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(synology-chat): prevent restart loop in startAccount#23074

fix(synology-chat): prevent restart loop in startAccount#23074
steipete merged 4 commits intoopenclaw:mainfrom
druide67:fix/synology-chat-restart-loop

druide67 commented Feb 22, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 22, 2026

Uh oh!

greptile-apps bot Feb 22, 2026

Uh oh!

greptile-apps bot Feb 22, 2026

Uh oh!

greptile-apps bot Feb 22, 2026

Uh oh!

druide67 commented Feb 24, 2026

Uh oh!

druide67 commented Feb 25, 2026

Uh oh!

Uh oh!

steipete commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

druide67 commented Feb 22, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type

Scope

What Changed

Security Impact

Repro + Verification

Human Verification

Compatibility

Greptile Summary

Confidence Score: 2/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

druide67 commented Feb 24, 2026

Uh oh!

druide67 commented Feb 25, 2026

Uh oh!

Uh oh!

steipete commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

druide67 commented Feb 22, 2026 •

edited by greptile-apps bot

Loading