Refactor Kafka publishing without DB outbox

docs/IM-Kafka接入联调测试文档.md

@@ -54,7 +54,6 @@ SOURCE docs/sql/IM-Kafka基础表SQL.sql;
 | 表 | 用途 |
 | --- | --- |
 | `im_kafka_consume_log` | 消费幂等、重试状态。 |
-| `im_kafka_outbox` | IM 侧可靠生产 Kafka 事件。 |
 | `im_kafka_dead_letters` | 死信记录与人工处理状态。 |
 | `im_messages` | 私聊消息存储。 |
 | `im_group_messages` | 群聊消息存储。 |
@@ -886,15 +885,7 @@ GET /v1/internal/admin-query/tenants/default/kafka/dead-letters/{dead_id}
 
 ### TC-KAFKA-030 Outbox 可靠投递
 
-目标：验证 IM 侧 Kafka Outbox 防止业务成功但 Kafka 丢事件。
-
-步骤：
-
-1. 临时停止 Kafka。
-2. 执行会产生 outbox 的操作，如发送消息、提交工作台事件。
-3. 查询 `im_kafka_outbox`。
-4. 恢复 Kafka。
-5. 等待 outbox worker 投递。
+目标：验证 IM 侧 Kafka 直接生产失败时不会产生 DB outbox，调用方收到发送失败。
 
 预期：
 
@@ -958,7 +949,7 @@ GET /v1/internal/admin-query/tenants/default/kafka/dead-letters/{dead_id}
 | 进入死信 | 查 `im_kafka_dead_letters.envelope/last_error`，修复后用重放命令。 |
 | 用户没有被踢下线 | 查目标 `user_id` 是否是 IM 用户 ID；是否连接在当前 IM 节点；跨节点踢人是否需要后续 Redis fanout 扩展。 |
 | 群治理未生效 | 查 `topic/version/actor_user_id` 是否正确，目标用户是否为群成员。 |
-| 消息未落库 | 查 `im_kafka_outbox` 是否 sent，`im.message.persist` 是否消费成功。 |
+| 消息未落库 | 查 `im.message.persist` 是否消费成功，以及 `im_kafka_consume_log.last_reason/last_error`。 |
 | 附件未绑定 | 查消息是否带附件、`im.file.lifecycle` 是否消费成功。 |
 | 内部 API 401 | 查 secret、签名文本、RequestURI、timestamp、nonce 是否一致。 |
 | 配置没有刷新 | 查是否发送 `im.config.event` 或 `im.cache.invalidate`，IM 是否清理了对应 namespace。 |
@@ -1023,7 +1014,7 @@ GET /v1/internal/admin-query/tenants/default/kafka/dead-letters/{dead_id}
 | 文件生命周期 | 上传完成、附件绑定、群文件登记/删除、OSS 元数据和引用表。 |
 | 工作台事件 | 会议、日报/月报、总经理信箱、红点/系统通知投递。 |
 | 死信闭环 | 死信查询、忽略、解决、重放，以及重放后二次成功/失败。 |
-| Outbox | Kafka 停止/恢复时 `im_kafka_outbox`、Admin outbox 的可靠投递。 |
+| Kafka 生产失败 | Kafka 停止/恢复时，确认 IM 不写 `im_kafka_outbox`，接口/WS 返回发送失败，恢复后可重新发送。 |
 | Admin 页面 | 操作单状态从 pending/running 到 succeeded/failed/dead 的页面联调。 |
 
 ### 10.2 2026-08-27 完整后端链路联调