你好，感谢提供详细的复现步骤，这个场景涉及到好友关系的删除和重新邀请的状态流转，分析如下：

**关于 code = 16**

错误码 16 通常表示服务端检测到当前操作不符合状态要求。在你的复现场景中：

A → B 的好友关系经历了：
1. 建立好友关系（A邀请 → B同意）
2. B 单方面删除 A（此时 B 的好友列表中已没有 A）
3. 再次建立好友关系（A邀请 → B同意）
4. A 单方面删除 B（此时 A 的好友列表中已没有 B）
5. A 再次邀请 B → 报错 code = 16

可能的原因是：
• 虽然 A 删除了 B，但服务端可能仍保留了之前的邀请记录或关系状态，导致再次邀请时触发重复校验
• 删除好友后，对应的好友请求记录清理可能存在延迟或需要双向删除才能完全重置状态

**关于 A 找不到 B 的邀请记录**

当 B 邀请 A 时，如果 A 登录后看不到该记录，可能的原因：
• 好友请求是定向推送的，如果 A 当时不在线，上线后的拉取机制可能存在延迟
• 或者 A 和 B 之间存在单向删除导致的数据不一致，服务端在生成请求列表时过滤掉了该记录

**建议排查方向**

1. **检查服务端日志**
   在 A 再次邀请 B 报错时，查看 im-server 的日志输出，确认具体的拒绝原因。

2. **查看数据库状态**
   直接查询数据库中  或相关表，看 A→B 和 B→A 的邀请记录状态。

3. **尝试双向删除**
   在第6步 A 删除 B 之后，确认 B 是否也删除了 A，或者由 B 主动删除 A 后再测试邀请流程。

4. **清除测试数据**
   如果条件允许，手动清理这两条测试账号之间的所有好友关系记录后重新测试，确认是否是历史脏数据导致。

这个流程确实有些特殊，如果排查后仍有疑问，建议提供：
• 服务端版本号
• 报错时的服务端日志
• 数据库中对应记录的状态

方便进一步定位问题。

你好，这个流程看起来确实有问题。经过分析，报错 code = 16 对应的是 `FRIEND_ALREADY_REQUEST`（已经发送过好友请求）。

**问题原因分析：**

根据你提供的复现步骤，在第5步（B 再次同意 A 的邀请）之后，好友请求应该被清除并且双方成为好友。但第6步 A 删除 B 后，再次邀请时却报 "已经发送过请求"。

这说明可能存在以下情况之一：

1. **好友请求缓存未清理**
   服务端在删除好友时，只删除了好友关系数据（FriendData），但没有清理好友请求记录（FriendRequest）。如果之前的好友请求记录还存在于缓存中，且状态不是 "已同意"，就会导致再次邀请时触发重复请求限制。

2. **请求状态异常**
   如果之前的好友请求在数据库中的状态异常（例如不是 Accepted 状态），那么 `saveAddFriendRequest` 逻辑会认为这是一个未处理的请求，从而返回 "already send request"。

**排查建议：**

1. **检查数据库中的好友请求记录**
   在 im-server 数据库的 `t_friend_request` 表中，查询 A 和 B 之间的好友请求记录：
   ```sql
   SELECT * FROM t_friend_request 
   WHERE (_from = 'A的uid' AND _to = 'B的uid') 
      OR (_from = 'B的uid' AND _to = 'A的uid')
   ORDER BY _update_dt DESC;
   ```
   重点看 `_status` 字段的值：
   - 0 = 已发送
   - 1 = 已同意
   - 2 = 已拒绝

2. **检查删除好友后的清理逻辑**
   确认 `DeleteFriendHandler` 执行后，双方的好友请求记录是否被正确清理。理论上删除好友不应该影响好友请求记录（因为已经处理过了），但如果之前存在脏数据，可能就会导致这个问题。

3. **im-server 日志**
   在执行第7步（A 再次邀请 B 报错）时，查看 im-server 的日志，确认 `saveAddFriendRequest` 返回了哪个错误码。

**临时解决方案：**

如果是脏数据导致的问题，可以通过以下 SQL 手动清理：
```sql
DELETE FROM t_friend_request 
WHERE (_from = 'A的uid' AND _to = 'B的uid') 
   OR (_from = 'B的uid' AND _to = 'A的uid');
```

建议先查一下数据库中这两个用户的好友请求记录状态，这样能定位问题的根源。