openclaw - 💡(How to fix) Fix Gateway error notifications for benign failures (e.g. config.schema.lookup path not found) leak into Telegram chat [1 comments, 2 participants]

1. Noise vs signal: config.schema.lookup returning "path not found" is a normal diagnostic outcome, not a system failure. Treating it the same as a real gateway crash dilutes the value of error notifications.
2. Conversation disruption: Users see cryptic internal error messages like Gateway: models.thinking failed that have nothing to do with their conversation. This is confusing and breaks the chat experience.

• Error severity should be classified before broadcasting: debug → log only, warn → log only, error → notify channel, critical → notify + escalate. Add error severity classification before broadcasting gateway notifications to the active channel. Filter out config.schema.lookup "not found" responses and similar benign diagnostic failures.

TL;DR

Classify error severity before broadcasting gateway notifications to filter out benign diagnostic failures like "path not found" responses from config.schema.lookup.

Guidance

• Introduce error severity classification (e.g., debug, warn, error, critical) to differentiate between benign lookup failures and genuine system failures.
• Modify the notification system to only broadcast errors with a severity of error or critical to the active channel.
• Consider adding a config option (e.g., gateway.notificationLevel) to control the verbosity of gateway notifications, allowing administrators to choose which types of errors to notify users about.
• Review and update the logging configuration to ensure that benign lookup failures are logged at the debug level instead of being broadcast to the user.

Example

# Example of error severity classification
error_severity = {
    'debug': ['path not found', 'invalid schema path'],
    'error': ['gateway crash', 'provider auth failure'],
    'critical': ['config corruption']
}

def classify_error(error_message):
    for severity, keywords in error_severity.items():
        if any(keyword in error_message for keyword in keywords):
            return severity
    return 'unknown'

# Example of filtering out benign diagnostic failures
if classify_error(error_message) in ['error', 'critical']:
    # Broadcast notification to the active channel
else:
    # Log the error at the debug level

Notes

The suggested fix assumes that the config.schema.lookup failures are currently being broadcast due to a lack of error severity classification. The introduction of a config option to control notification verbosity can provide flexibility in managing which errors are notified to users.

Recommendation

Apply a workaround by introducing error severity classification and filtering out benign diagnostic failures, as this approach directly addresses the issue of noise vs signal and conversation disruption.