fix: feishu streaming cards, structured errors, and migration robustness#444
fix: feishu streaming cards, structured errors, and migration robustness#444yaojin3616 merged 2 commits intomainfrom
Conversation
- Add streaming interactive card builder and tool-error helpers in feishu.py - Introduce FeishuAPIError with structured fields and user-friendly messages - Fix add_participants migration to handle missing username column - Refactor chat session permissions: agent creator can view/manage all sessions - Remove deprecated open_id param from send_feishu_message tool (use user_id) - Expand chat session API tests
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a53c2a9ba
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if resp.status_code >= 400: | ||
| logger.warning( | ||
| f"[Feishu] {stage} HTTP failure " | ||
| f"(http_status={resp.status_code}, message_id={message_id}, body={str(data)[:300]})" | ||
| ) | ||
| raise RuntimeError(f"Feishu {stage} HTTP {resp.status_code}") | ||
|
|
There was a problem hiding this comment.
Raise on HTTP-level Feishu API failures
The resp.status_code >= 400 branch now only logs and falls through, so _parse_api_response may return as if successful when Feishu responds with an HTTP error payload that lacks a nonzero code (or unexpectedly includes code: 0). In that case callers like send_message and patch_message do not get a FeishuAPIError, which drops HTTP error context and can mis-handle provider outages as normal responses. This is a regression from the previous behavior that raised immediately on HTTP failures.
Useful? React with 👍 / 👎.
Combine both approaches: check for identities table first (new schema where username moved to identities), fall back to users.username column (old schema), then fall back to display_name only.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3bcb39dde8
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| resp = await _try_send(config.app_id, config.app_secret, target_member.external_id, "user_id") | ||
| if resp.get("code") == 0: |
There was a problem hiding this comment.
Restore open_id fallback when user_id delivery fails
_send_feishu_message now always delivers with receive_id_type="user_id" and no longer retries open_id. In this codebase, Feishu org sync still pulls members with user_id_type=open_id and stores that value into external_id (see org_sync_adapter comments around that mapping), so many existing members will carry an open_id-shaped identifier. With this change, those recipients now hard-fail sends even though open_id is present and used to be a working fallback, which breaks proactive Feishu messaging for tenants without employee_id scope/re-sync.
Useful? React with 👍 / 👎.
Summary
_build_streaming_card构建飞书交互卡片,支持 thinking 展示和工具状态滚动FeishuAPIError,保留 HTTP 状态码、错误码、log_id 等字段,提供用户友好的错误消息add_participants迁移兼容无username列的数据库环境send_feishu_message工具中的open_id参数,统一使用user_idTest plan
username列的数据库上运行add_participants迁移scope=all会话列表backend/tests/test_chat_sessions_api.py全部通过