Skip to content

[Bug]: nextcloud-talk plugin crashes on start - start() resolves without holding HTTP server reference causing EADDRINUSE crash loop #27897

@JoseRamirezMoreno

Description

@JoseRamirezMoreno

Summary

The nextcloud-talk plugin's start() method resolves its promise without retaining a reference to the HTTP server. The plugin subsystem interprets this as "plugin exited" and immediately schedules a restart. The restarted instance finds the port still bound, producing EADDRINUSE, which crashes the gateway in a tight loop and takes down all other channels.

Steps to reproduce

  1. Configure the nextcloud-talk plugin in openclaw.json with a valid webhookPort (e.g. 8788), botSecret/botSecretFile, and webhookPublicUrl.
  2. Ensure the port is not already in use.
  3. Start (or restart) the OpenClaw gateway.
  4. Watch the gateway log immediately after startup.

Expected behavior

The nextcloud-talk plugin starts, binds the webhook HTTP server on the configured port, and stays running. The plugin subsystem registers it as active and does not schedule a restart.

Actual behavior

  • Plugin logs webhook listening on <webhookPublicUrl>
  • ~11ms later: [plugin/nextcloud-talk] auto-restart attempt 1/10 in 5s
  • After 5s delay: new instance attempts to bind the same port
  • Error: listen EADDRINUSE :::<port> — gateway exits with code=1
  • systemd/process manager restarts the gateway → loop repeats indefinitely
  • All other channels (e.g. WhatsApp) are taken down with the gateway

OpenClaw version

2026.2.23

Operating system

Linux (Debian-based, systemd user service)

Install method

npm global

Logs, screenshots, and evidence

[nc-talk] webhook listening on https://<host>/nextcloud-talk-webhook
[plugin/nextcloud-talk] auto-restart attempt 1/10 in 5s
Error: listen EADDRINUSE :::8788
    at Server.setupListenHandle [as _listen2] ...
[gateway] exit code=1

Cycle repeats on every gateway start with the plugin enabled.

Impact and severity

  • Affected: Any user who configures the nextcloud-talk plugin with webhookPort
  • Severity: Critical — crashes the gateway immediately, taking down ALL channels
  • Frequency: 100% reproducible on every gateway start with the plugin enabled
  • Consequence: Plugin is completely unusable in its bundled form; only workaround is "enabled": false

Additional information

Root cause hypothesis: start() creates an HTTP server but resolves the returned promise before (or without waiting for) the server's listening event. The plugin subsystem sees a resolved start() as "plugin has exited" and schedules the auto-restart immediately. The original server is still holding the port when the restart fires.

Workaround: Set "enabled": false in the nextcloud-talk plugin config and run a standalone webhook receiver as a separate process/service that forwards inbound Nextcloud Talk messages to OpenClaw via the /v1/chat/completions HTTP endpoint.

Also observed: The ON badge on the Chrome Browser Relay extension does not clear when the attached tab navigates to a new page (full navigation), giving a false impression that the tab is still attached. May be worth a separate issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions