Makeplane项目中Webhook返回重复Assignee数据的Bug分析

问题背景

在Makeplane项目管理系统中，当用户通过Webhook监听issue更新事件时，系统返回的assignees字段出现了异常行为。该字段本应只返回当前被分配的用户列表，但实际上却返回了历史上所有曾经被分配过的用户记录，导致数据重复冗余。

技术现象

通过实际测试发现，当用户反复修改issue的负责人时，Webhook返回的JSON数据中assignees数组会不断累积历史分配记录。例如：

1. 用户A被分配后，assignees显示1条用户A记录
2. 改为用户B后，assignees显示用户A+用户B两条记录
3. 改回用户A后，assignees显示用户A+用户B+用户A三条记录

这种累加行为明显不符合预期，理想情况下assignees应该只反映当前issue的实际分配状态。

问题根源

经过Makeplane团队分析，这个问题可能源于：

1. 状态追踪逻辑错误：系统可能错误地将assignee变更历史记录与当前状态混合处理
2. 数据持久化问题：数据库可能保留了所有assignee变更记录，但在查询时未正确过滤
3. Webhook数据处理层缺陷：在准备Webhook响应数据时，可能错误地包含了变更历史而非当前状态

影响评估

该Bug会导致：

• Webhook消费者接收到错误的数据状态
• 下游系统可能基于重复数据做出错误决策
• 数据传输量不必要地增大
• 系统资源浪费在冗余数据处理上

解决方案建议

针对这类问题，建议采取以下技术措施：

1. 明确数据边界：区分变更历史和当前状态，Webhook只应返回当前状态
2. 添加数据过滤：在Webhook数据处理层增加状态过滤逻辑
3. 引入数据版本控制：如果需要追踪变更历史，应该使用专门的变更日志字段
4. 完善测试用例：增加针对assignee变更场景的Webhook响应测试

最佳实践

对于类似项目管理系统的Webhook实现，建议：

• 保持Webhook响应数据的简洁性和准确性
• 为历史变更提供专门的事件类型和字段
• 在文档中明确说明各字段的含义和预期行为
• 考虑提供数据精简选项，允许消费者选择只接收必要字段

Makeplane团队已确认该问题并着手修复，这体现了开源项目对用户反馈的快速响应能力。对于开发者而言，理解这类问题的解决思路有助于构建更健壮的项目管理系统。