hermes - 💡(How to fix) Fix [Bug] Feishu/Lark: bot_p2p_chat_entered_v1 events flood errors.log with 'processor not found' [1 comments, 1 participants]

The Feishu (Lark) SDK continuously pushes im.chat.access_event.bot_p2p_chat_entered_v1 events to the gateway. These events have no registered processor in Hermes, causing the error log to be flooded with identical error messages at high frequency (every few seconds). ERROR Lark: handle message failed, message_type: event, message_id: <uuid>, trace_id: <uuid>, err: processor not found, type: im.chat.access_event.bot_p2p_chat_entered_v1 [conn_id=<id>] This event fires every time the user opens the bot chat window, and can generate dozens of errors per minute. It makes the error log unusable for debugging actual issues. 2. Filter out unhandled event types at the Lark SDK level before they reach the error handler In the Feishu platform adapter (gateway/platforms/feishu.py), add bot_p2p_chat_entered_v1 and similar access events to an ignored/acknowledged event list, or register a pass-through processor that returns 200 without logging an error.

TL;DR

Implementing a no-op handler or filtering unhandled event types for im.chat.access_event.bot_p2p_chat_entered_v1 events in the Feishu platform adapter can resolve the issue of flooded error logs.

Guidance

• Identify and list all event types that are currently unhandled and causing errors, such as bot_p2p_chat_entered_v1, to determine which events need to be either ignored or handled with a no-op processor.
• In gateway/platforms/feishu.py, add a mechanism to either ignore these events or register a pass-through processor that returns a success response (200) without logging an error, thus preventing the error log from being flooded.
• Consider implementing a filter at the Lark SDK level to prevent unhandled event types from reaching the error handler, as an alternative or complementary solution.
• Review the error handling logic to ensure that once the no-op handler or filtering is in place, the error logs will indeed decrease in volume and become more useful for debugging actual issues.

Example

# Example of a no-op handler in feishu.py
def noop_handler(event):
    # Silently accept the event without logging an error
    return 200

# Register the no-op handler for specific event types
event_handlers = {
    'im.chat.access_event.bot_p2p_chat_entered_v1': noop_handler,
    # Add other event types as needed
}

Notes

The solution assumes that the Feishu SDK and Hermes Agent versions are compatible and that the issue is solely due to unhandled event types. It's also important to monitor the system after implementing the fix to ensure that the error log volume decreases and that the no-op handler or filtering does not introduce any unintended side effects.

Recommendation

Apply a workaround by registering a no-op handler for unhandled event types, as this approach directly addresses the issue of flooded error logs without requiring significant changes to the existing system.