Feishu: all messages permanently ignored as 'old message after restart' after every daemon restart (v1.3.3-beta.2)

[zhangyanbo2007]

Bug Description

After every daemon restart, cc-connect permanently ignores ALL Feishu messages, logging "feishu: ignoring old message after restart" for every incoming message — even messages sent minutes after the restart. This makes the Feishu bot completely unresponsive after any restart.

Reproduction Steps

1. Start cc-connect with a Feishu platform: cc-connect --force
2. Wait for WebSocket connection to establish
3. Send any message (e.g. /list) from Feishu chat
4. Observe in logs: feishu: ignoring old message after restart
5. The message is never processed — /list returns nothing, no responses are sent
6. All subsequent messages are also ignored — the bug is permanent, not temporary

Expected Behavior

Messages sent AFTER the daemon restart should be processed normally. Only truly duplicate/stale messages from before the restart should be filtered.

Environment

• cc-connect v1.3.3-beta.2 (commit f6a1a79)
• Platform: Feishu
• OS: Linux

Attempted Workarounds (all failed)

• Setting past_id_tracking = False in session JSON — daemon ignores this field, filtering persists
• Waiting 10+ seconds after restart before sending messages — still filtered
• Multiple restart cycles — bug persists on every restart
• Setting past_id_tracking = False before daemon startup (so it reads False from disk) — still ignored

Log Evidence

time=2026-05-13T15:05:51 level=INFO msg="cc-connect is running"
2026/05/13 15:05:51 [Info] [connected to wss://msg-frontier.feishu.cn...]

# Message sent 2 minutes AFTER restart:
time=2026-05-13T15:07:51 level=DEBUG msg="feishu: ignoring old message after restart" create_time=1778655883913

# Message sent 3 minutes AFTER restart — still ignored:
time=2026-05-13T15:08:19 level=DEBUG msg="feishu: ignoring old message after restart" create_time=1778655912439

# Messages sent 7+ minutes after restart — still ignored:
time=2026-05-13T15:13:30 level=DEBUG msg="feishu: ignoring old message after restart" create_time=1778656222589

Analysis

The past_id_tracking mechanism appears to permanently filter all incoming messages after startup, regardless of when the messages were actually created. The JSON field past_id_tracking does not control this behavior — the daemon's internal filtering logic is separate and cannot be disabled externally.

The filtering logic seems to use a timestamp cutoff that is set incorrectly on startup, causing it to reject all subsequent messages rather than just the initial WebSocket replay batch.

Impact

This makes cc-connect completely unusable for Feishu after any daemon restart — including normal operations like config changes, session management, or system updates that require a restart.

[github-actions]

👋 Hi @zhangyanbo2007! Thanks for opening your first issue here!

We'll review it as soon as possible. While waiting, please make sure:

• You've provided enough details about the issue
• Any error messages are included in full
• For feature requests, describe your use case

Thanks for your feedback!

[chenhg5]

Thanks for the detailed bug report with clear reproduction steps. This is a critical P0 issue - the past_id_tracking mechanism is permanently filtering all messages after a daemon restart, making Feishu completely unusable.

A fix is being developed as high priority. Please follow this issue for updates.

[zhangyanbo2007]

Deep Technical Analysis: Root Cause Identified

After further investigation of the compiled binary (v1.3.2, commit 19406df), I've identified the actual root cause — the filtering mechanism is NOT PastIDTracking as initially assumed.

The Real Filtering Logic

The message deduplication is implemented in core/dedup.go:

var StartTime = time.Now()  // Package-level variable, initialized at Go runtime package load

func IsOldMessage(msgTime int64) bool {
    return msgTime < (StartTime.UnixMilli() - 2000)  // Hardcoded 2-second grace period
}

In platform/feishu/feishu.go (around line 948-954), every incoming Feishu WebSocket message is checked:

if core.IsOldMessage(*msg.CreateTime) {
    slog.Debug(p.tag()+": ignoring old message after restart", "create_time", *msg.CreateTime)
    return nil  // Message silently dropped, no error sent to user
}

Why This Causes the Bug

StartTime = time.Now() is a package-level variable initialized when the Go runtime loads the core package. This happens before the WebSocket connection is established (which starts in a goroutine later). There are two problems:

1. Timing gap: The WebSocket client (larkws.NewClient) starts in a goroutine after the main engine initialization. Messages delivered immediately upon connection may have CreateTime timestamps that are close to or before StartTime due to the initialization delay.

2. Permanent filtering: In some restart scenarios, StartTime appears to be set to a timestamp that is later than the CreateTime of new messages for a prolonged period. This explains why the original issue describes the bug as permanent (messages ignored forever), while in other restarts it's temporary (~2-5 minutes).

Why past_id_tracking = False Doesn't Help

The PastIDTracking field in sessionSnapshot is completely unrelated to message filtering. It controls KnownAgentSessionIDs() — a session ownership deduplication mechanism that checks whether a session's agent_session_id has been seen before. Setting past_id_tracking = False only affects session tracking, not the IsOldMessage() check.

Suggested Fix

1. Use WebSocket connection establishment time instead of package-level StartTime as the cutoff. Record the actual moment when the Feishu SDK reports connection success, and use that timestamp in IsOldMessage().

2. Make the grace period configurable (currently hardcoded to 2 seconds). A grace period of 30-60 seconds would allow for WebSocket connection latency and message delivery skew.

3. Add a safety timeout: If IsOldMessage() has been filtering for more than N seconds after startup, automatically disable the filter. This prevents the permanent-filtering scenario.

---

This analysis was done while developing session-name-sync, a Claude Code skill that bidirectionally syncs session names between Claude Code and cc-connect. The bug was encountered during testing of the skill's register mode, which requires stopping and restarting the cc-connect daemon.