Fix the limitation on the number of tables in cards caused by Feishu

[opcache]

📝 Description

This PR addresses the Feishu API error triggered when the number of Markdown tables in an Interactive Card exceeds the platform limit. The error manifests as code=230099 msg=Failed to create card content, ext=ErrCode: 11310; ErrMsg: card table number over limit.

Key modifications:

1. Updated the Send method in feishu_64.go (lines 115-147) to implement auto-downgrade logic: prioritize card-based message delivery, detect table limit errors, and automatically fall back to plain text delivery if the error is triggered.
2. Added a new sendText helper method (lines 735-762) to handle plain text message sending via Feishu's MsgTypeText API.
3. Imported the strings package for error message pattern matching and added warning logging to facilitate troubleshooting of table limit issues.

Implementation Logic

1st Attempt: Try sending Interactive Card
    ↓ Success
Return success

    ↓ Failure (Error Code 11310)
2nd Attempt: Try sending plain Text message
    ↓ Success
Return success (with message format downgraded)

    ↓ Failure
Return error

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

Fixes #XXX (replace XXX with the actual issue number; remove this line if no related issue exists)

📚 Technical Context (Skip for Docs)

• Reference URL: https://open.feishu.cn/document/common-capabilities/message-card/message-card-design-guide/limitations
• Reasoning: Feishu Open Platform enforces a strict limit on the number of tables allowed in a single Interactive Card. When this limit is exceeded, the API returns error codes 11310/230099 and rejects the request. Implementing downgrade logic ensures message delivery reliability by switching to plain text instead of failing completely.

🧪 Test Environment

• Hardware: PC
• OS: Ubuntu 24.04 / WIN10
• Model/Provider: Feishu Open Platform API v4
• Channels: Feishu

📸 Evidence (Optional)

Click to view Logs/Screenshots

Error Log Before Fix

feishu api error (code=230099 msg=Failed to create card content, ext=ErrCode: 11310; ErrMsg: card table number over limit)
plaintext

Warning Log After Fix

WARNING: Feishu card table limit exceeded, downgrading to plain text: feishu api error (code=230099 msg=Failed to create card content, ext=ErrCode: 11310; ErrMsg: card table number over limit)
plaintext

Successful Delivery Confirmation

2026-03-18 10:00:00 [INFO] Feishu plain text message sent successfully, message ID: msg_xxx
plaintext

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[Copilot]

Pull request overview

Improves Feishu outbound message reliability by falling back to plain-text messages when Interactive Card delivery fails due to specific card limitations.

Changes:

• Add a fallback flow in FeishuChannel.Send to retry as plain text when card sending fails with certain “card limit” errors.
• Introduce sendText helper to send Feishu text messages via the same IM message create API.
• Add minimal logging for the fallback path and import strings for error matching.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yinwm]

Code Review

Thanks for implementing the fallback logic! The approach is solid.

One Issue to Fix

The error detection pattern is too broad:

isCardLimitError := strings.Contains(errMsg, "table") ||
    strings.Contains(errMsg, "230099") ||
    strings.Contains(errMsg, "11310")

The keyword "table" is too generic and could match unrelated error messages (e.g., database errors containing "table"). This might trigger unnecessary fallbacks.

Suggestion: Only match the specific error code:

isCardLimitError := strings.Contains(errMsg, "11310")

Or be more precise with the pattern:

isCardLimitError := strings.Contains(errMsg, "ErrCode: 11310")

Other than that, LGTM! 👍

[opcache]

@yinwm Updated to only match error code 11310

[yinwm]

LGTM! The fallback logic is correct and handles the card table limit error gracefully.

Two minor informational notes for future consideration:

1. The error wrapping in sendText drops the original error details — consider fmt.Errorf("feishu send text: %w: %v", channels.ErrTemporary, err) for better debugging
2. EditMessage and SendPlaceholder also use card sending and could hit the same 11310 error — consider adding similar fallback if needed

These are minor and don't block the merge.

[Orgmar]

@opcache Smart approach on the Feishu card table limit fix. Auto-downgrading to plain text when the API rejects the card keeps message delivery reliable without losing content. The fallback flow is clean and the warning logging makes it easy to spot when downgrades happen.

We're building a PicoClaw Dev Group on Discord for contributors to collaborate. If you're interested, drop an email to support@sipeed.com with subject [Join PicoClaw Dev Group] opcache and we'll get you the invite link!