openclaw - 💡(How to fix) Fix iMessage subsystem auto-restarts in 5s loop on large `chat.db` (chats.list timeout) [2 comments, 2 participants]

[imessage] [default] starting provider (/opt/homebrew/bin/imsg db=/Users/.../chat.db) [imessage] imsg rpc not ready after 14806ms (Error: imsg rpc timeout (chats.list)) [imessage] [default] auto-restart attempt 1/10 in 5s [imessage] [default] starting provider (/opt/homebrew/bin/imsg db=...) [imessage] imsg rpc not ready after 14806ms (Error: imsg rpc timeout (chats.list)) ... (10 attempts, then exits)

TL;DR

Increase the chatsListTimeoutMs value to a higher number, such as 60000, to allow the chats.list RPC to complete without timing out.

Guidance

• Identify the current value of chatsListTimeoutMs and consider increasing it to a higher value, such as 60000, to accommodate the large chat.db file.
• Verify that the imsg binary is healthy by running the command /opt/homebrew/bin/imsg chats --limit 2 and checking the response time.
• Consider implementing the proposed medium-term fix of making the initial chats.list non-blocking to prevent the event loop from being blocked.
• Test the workaround by setting channels.imessage.enabled: false to confirm that it resolves the issue, but note that this will disable iMessage functionality.

Example

No code snippet is provided as it is not necessary for this issue.

Notes

The issue is specific to the imsg rpc JSON-RPC chats.list on a large chat.db file, and the proposed fixes are targeted at addressing this specific problem. The imsg binary itself has been verified to be healthy.

Recommendation

Apply the workaround by increasing the chatsListTimeoutMs value, as this is a simple and effective way to resolve the issue without disabling iMessage functionality entirely.