Feishu Plugin: Message Redelivery + Timezone Handling Error (Ghost Message Replay) #10803
Description
Summary
After OpenClaw update/gateway restart, the Feishu plugin receives a large number of duplicate historical messages (Gho
st Message Replay). Additionally, there is a timezone handling error causing messages to display approximately 8 hours
later than the actual send time.
Reproduction Steps
- Send messages normally via Feishu channel (e.g., send a message at 23:35)
- Execute
openclaw updateor restart the gateway - After WebSocket reconnects, immediately receive redelivered historical messages
- Message timestamps display incorrectly (a 23:35 message shows as 06:41 the next day)
Expected Behavior
- Messages should be processed only once without redelivery
- Message timestamps should correctly display in local time (Beijing Time)
Actual Behavior
- Duplicate Delivery: Messages with the same content are processed multiple times (different message_ids)
- Timezone Error: Feishu message timestamps in Beijing Time are misinterpreted as UTC, then converted back to Beij
ing Time with +8 hours offset
Timeline Evidence
| Actual Send Time | Message Content | OpenClaw Display Time | Delay |
|---|---|---|---|
| 02-06 23:35 | ChatGPT discussion... | 02-07 06:41 | ~7h |
| 02-06 23:58 | Please restart Xiaoke | 02-07 07:03 | ~7h |
| 02-07 00:20 | The time is wrong... | 02-07 07:25 | ~7h |
Log Evidence
WebSocket reconnect triggers duplicate delivery:
2026-02-07T00:26:50.507Z info feishu-monitor Stopping Feishu WS client... 2026-02-07T00:26:53.631Z info feishu-monitor
Feishu WebSocket connection established 2026-02-07T00:26:53.908Z info feishu-monitor [ws] ws client ready
Incorrect message timestamp (session file):
{
"timestamp": "2026-02-06T22:41:34.968Z", // Stored UTC time
"message": {
"role": "user",
"content": [{"text": "ChatGPT discussion..."}]
}
}
// Actual send time: 02-06 23:35 (Beijing Time)
// Stored time: 02-06 22:41:34 (UTC) → Converted to Beijing Time: 02-07 06:41
Root Cause Analysis
1. Message Redelivery
• After WebSocket disconnection and reconnection, Feishu server redelivers unacknowledged messages
• message_id is different (om_x100b576... vs om_x100b575...)
• Feishu generates a new message_id for redelivered messages
2. Timezone Handling Error
• OpenClaw incorrectly treats Feishu message timestamps (Beijing Time) as UTC
• Then adds 8 hours to convert back to Beijing Time, resulting in 8-hour delay
Environment
• OpenClaw Version: 2026.2.3-1
• Feishu Plugin: @openclaw/feishu (built-in plugin)
• Connection Mode: WebSocket (Long Connection)
• OS: macOS 26.2 (arm64)
• Node.js: 25.6.0
Proposed Fixes
1. Message Deduplication
• Implement deduplication based on content hash (not message_id, which changes on redelivery)
• Or implement time window filtering (e.g., only process messages within 30 minutes)
2. Timezone Handling
• Correctly identify the timezone of Feishu message timestamps
• Or use the create_time field from Feishu API instead of locally generated timestamps
3. Message Acknowledgment
• Ensure proper message consumption acknowledgment is sent to Feishu server
• Prevent message redelivery after WebSocket reconnection
Workaround (Immediate)
Add safety policies in MEMORY.md:
• Night mode (00:00-08:00): Block dangerous operations
• Delayed message drop: Don't process messages older than 30 minutes
• Secondary confirmation for dangerous actions (restart, exec, etc.)
Additional Context
• This issue occurs consistently after every openclaw update or gateway restart
• The duplicate messages have different message_id values, suggesting Feishu regenerates them
• The ~8 hour delay matches the Beijing Time (UTC+8) offset
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Related Issues: Possibly related to #171 (conflict with built-in Feishu plugin)