Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix False-positive WARN: "closed before connect" floods logs from internal health probes [1 pull requests, 1 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#60510•Fetched 2026-04-08 02:50:11
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
Ramadas108Ramadas108
Participants
NilsR0711NilsR0711Ramadas108Ramadas108
Timeline (top)
commented ×1cross-referenced ×1referenced ×1

Error Message

The gateway emits a WARN-level log every ~120 seconds: In gateway-cli-CWpalJNJ.js line ~27459 the code logs any WS close before handshake as WARN, unless the UA contains swiftpm-testing-helper. Internal probes have no UA, so they fall through and log as WARN.

  • ~700 false WARN entries per day

Root Cause

In gateway-cli-CWpalJNJ.js line ~27459 the code logs any WS close before handshake as WARN, unless the UA contains swiftpm-testing-helper. Internal probes have no UA, so they fall through and log as WARN.

Fix Action

Fixed

PR fix notes

PR #60536: fix(ws): downgrade internal health probe pre-handshake close from WARN to debug

Description (problem / solution / changelog)

Summary

  • Adds isInternalProbeClose() helper in ws-connection.ts to suppress false-positive WARN logs generated by the gateway's own health probes
  • Probes connecting from loopback with origin matching the gateway bind address and close code 1000 now log at debug instead of warn
  • All other pre-handshake closes (external IPs, non-1000 codes) continue to log as WARN — no real errors are hidden

Root cause

probe.ts creates a GatewayClient with mode: GATEWAY_CLIENT_MODES.PROBE, calls client.stop() immediately after a successful RPC response, which fires the close event before handshake state is set. The existing !client guard then unconditionally logs WARN.

Test plan

  • Gateway restart: confirm no closed before connect WARN entries from 127.0.0.1 with origin http://127.0.0.1:18789 and code 1000
  • Confirm probe-unrelated pre-handshake closes still log as WARN
  • pnpm build && pnpm check && pnpm test passes

Code reviewed and test plan validated with AI-assisted analysis.

Closes #60510

Changed files

  • src/gateway/server/ws-connection.ts (modified, +20/-3)

Code Example

closed before connect conn=... remote=127.0.0.1 origin=http://127.0.0.1:18789 ua=n/a code=1000
RAW_BUFFERClick to expand / collapse

Issue

The gateway emits a WARN-level log every ~120 seconds:

closed before connect conn=... remote=127.0.0.1 origin=http://127.0.0.1:18789 ua=n/a code=1000

On this instance I am seeing 600-700+ entries per day. These are the gateway's own health probes connecting to itself, verifying reachability, and closing cleanly (code 1000, duration 1-3ms).

Root cause

In gateway-cli-CWpalJNJ.js line ~27459 the code logs any WS close before handshake as WARN, unless the UA contains swiftpm-testing-helper. Internal probes have no UA, so they fall through and log as WARN.

Evidence

  • All entries originate from 127.0.0.1 with origin=http://127.0.0.1:18789
  • Close code is always 1000 (normal/clean closure)
  • Duration is 1-3ms (probe opens then immediately stops)
  • RPC probe: ok, 31ms latency confirms probes work
  • The probe-DQJC7Z64.js module creates a GatewayClient in PROBE mode, calls client.stop() on success, which triggers the close handler before handshake completes

Impact

  • ~700 false WARN entries per day
  • Wastes ~30-50MB of log disk per day just on these
  • Drowns out real connection issues in log grep/monitoring
  • Misleading for anyone monitoring log severity

Suggested fix

Downgrade or suppress the log when:

  1. remote is loopback AND origin matches the gateway's own bind address AND code === 1000
  2. Or: explicitly recognize probe-mode client connections (they use GATEWAY_CLIENT_MODES.PROBE)
  3. Or: add an isInternalProbe() helper alongside the existing isNoisySwiftPmHelperClose() filter

Environment

  • OpenClaw 2026.4.2 (d74a122)
  • Linux x64, Node 22.22.0

extent analysis

TL;DR

Downgrade or suppress the log for internal health probes by adding a conditional check for loopback connections with a close code of 1000.

Guidance

  • Identify and modify the logging condition in gateway-cli-CWpalJNJ.js to exclude internal probes based on the suggested fix criteria.
  • Consider adding an isInternalProbe() helper function to filter out probe-mode client connections.
  • Verify the fix by monitoring log entries for the WARN-level log and checking if the number of false positives decreases.
  • Review the logging configuration to ensure that the suppression of internal probe logs does not mask real connection issues.

Example

if (remote === '127.0.0.1' && origin === 'http://127.0.0.1:18789' && code === 1000) {
  // Suppress log for internal health probes
  return;
}

Notes

The suggested fix assumes that the internal probes will always originate from 127.0.0.1 and have a close code of 1000. If this is not the case, additional logging conditions may need to be added.

Recommendation

Apply workaround by modifying the logging condition to exclude internal probes, as downgrading the version may not be feasible or desirable. This approach allows for a targeted fix without affecting other parts of the system.

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…
#docker error#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

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

Back to top recommendations

TRENDING