Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Gateway should log warning when message is dropped due to allow: false [2 pull requests, 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#58570•Fetched 2026-04-08 02:00:54
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
UBIpromoterUBIpromoter
Participants
UBIpromoterUBIpromoter
Timeline (top)
cross-referenced ×2mentioned ×1referenced ×1subscribed ×1

When a message resolves to a channel config entry that has allow: false, the gateway drops the message silently — no log output, no warning, nothing. This makes silent policy denials indistinguishable from transport or routing bugs during incident response.

Root Cause

When a message is dropped because a resolved channel route has allow: false, emit a structured warning log entry including:

Fix Action

Fixed

PR fix notes

PR #58633: fix(slack): add warning log when channel is dropped due to allow:false

Description (problem / solution / changelog)

Summary

When a message resolves to a channel config entry that has allow:false, the gateway now logs a warning instead of a verbose log. This makes access denial more visible in production environments.

Issue

Fixes #58570

Changes

  • Import warn from openclaw/plugin-sdk/runtime-env
  • Change the log level from logVerbose to warn when a channel is dropped due to allow:false
  • Include the allow value in the log message for clarity

Test Plan

  • Code compiles without errors
  • Log message now includes allow=false in the output for easy debugging

Changed files

  • extensions/slack/src/monitor/context.ts (modified, +2/-2)

PR #58640: fix(slack): add warning log when channel is dropped due to allow:false

Description (problem / solution / changelog)

Summary

When a message resolves to a channel config entry that has allow:false, the gateway now logs a warning instead of a verbose log. This makes access denial more visible in production environments.

Issue

Fixes #58570

Changes

  • Import warn from openclaw/plugin-sdk/runtime-env
  • Change the log level from logVerbose to warn when a channel is dropped due to allow:false
  • Include the allow value in the log message for clarity

Test Plan

  • Code review: passed
  • Grep regression check: passed
  • CI: pending (build environment incomplete — node_modules not installed in fork)

Review Summary

See attached test record for full evidence.

Changed files

  • extensions/slack/src/monitor/context.ts (modified, +2/-3)
RAW_BUFFERClick to expand / collapse

Summary

When a message resolves to a channel config entry that has allow: false, the gateway drops the message silently — no log output, no warning, nothing. This makes silent policy denials indistinguishable from transport or routing bugs during incident response.

Requested behavior

When a message is dropped because a resolved channel route has allow: false, emit a structured warning log entry including:

  • Channel/provider (e.g. discord, telegram)
  • Account or guild identifier if relevant
  • Route key / channel ID
  • Machine-readable reason like channel_not_allowed

Ideally rate-limit or dedupe the warning so a busy denied channel doesn't spam logs.

Context

This came up during a real incident on 2026-03-31. A channel was configured with an explicit binding but allow: false, and messages were silently dropped for hours before anyone noticed. The only way to diagnose was to compare config entries line by line — no log trail existed.

What this is NOT asking for

This is not a request to change config semantics (e.g., defaulting explicit bindings to allow: true). The fail-closed model is fine. The ask is purely observability: when a policy decision drops a message, log it.

Filed by Deploy Jane (OpenClaw AI agent) on behalf of @UBIpromoter, from a post-mortem discussion.

extent analysis

TL;DR

Implement a logging mechanism to emit a structured warning log entry when a message is dropped due to a channel config entry with allow: false.

Guidance

  • Identify the specific code path where messages are dropped silently due to allow: false and add a logging statement to emit a warning log entry with relevant details.
  • Consider implementing rate-limiting or deduplication to prevent log spam from busy denied channels.
  • Review the logging configuration to ensure that warning log entries are properly configured to be visible and actionable during incident response.
  • Verify that the logging mechanism is working as expected by testing it with a channel config entry with allow: false and checking the log output.

Notes

The solution will depend on the specific logging framework and configuration used in the application, as well as the details of the channel config entry and message handling code.

Recommendation

Apply a workaround by adding a logging statement to the code path where messages are dropped due to allow: false, as this will provide the necessary observability to diagnose and respond to incidents without changing the underlying config semantics.

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…
#output truncation#response parsing#generation error#database connection#vector store

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 - ✅(Solved) Fix Gateway should log warning when message is dropped due to allow: false [2 pull requests, 1 participants]