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

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

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

方便进一步定位问题。