Tutanota日历重复事件更新问题分析与解决方案

问题概述

在Tutanota日历功能中，当组织者修改重复事件并取消某个特定日期的事件时，系统未能正确地将这一变更通知给所有参与者。具体表现为：组织者删除单个事件实例后，参与者端仍然显示该事件未被删除，直到后续发送其他更新（如修改事件标题）时问题才得到解决。

技术背景

Tutanota是一款注重隐私安全的电子邮件和日历服务，其日历功能支持创建重复事件并允许修改单个实例。在iCalendar协议标准中，重复事件的修改通过"RECURRENCE-ID"属性来标识被修改的特定实例，而"EXDATE"属性则用于标识被排除的实例。

问题根源分析

经过代码审查，发现问题主要出在以下两个关键位置：

1. 在CalendarEventModelStrategy.ts文件中，系统在处理重复事件更新时，错误地将被删除的事件实例也添加到了recurrenceIds集合中。

2. 在CalendarNotificationModel.ts文件中，通知模型同样错误地包含了这些本应被排除的事件实例。

这种实现方式违背了iCalendar协议规范，导致生成的ICS文件不包含正确的排除信息，进而使参与者客户端无法正确识别和删除指定的实例。

解决方案

正确的实现应该是：

1. 对于被删除的事件实例，不应将其添加到recurrenceIds集合中，因为根据协议定义，这些实例将不再发生。

2. 通知模型生成时，应严格区分被修改的实例和被排除的实例，确保EXDATE属性正确包含在生成的ICS文件中。

实现细节

修复方案需要调整事件模型的逻辑处理流程：

1. 当用户删除单个实例时，系统应将其标记为排除而非修改。

2. 生成通知时，确保排除的实例仅出现在EXDATE属性中，而不出现在RECURRENCE-ID集合中。

3. 对于ICS文件生成逻辑，需要确保排除规则被正确序列化。

影响范围

该问题主要影响以下场景：

1. 组织者删除重复事件中的单个实例
2. 组织者修改重复事件规则并排除特定日期
3. 涉及多个参与者的重复事件更新

验证方法

为确保修复有效，应进行以下测试：

1. 创建每周重复事件并邀请参与者
2. 参与者接受邀请后，组织者删除单个实例
3. 验证参与者端是否正确移除了指定实例
4. 检查生成的ICS文件是否包含正确的EXDATE属性

总结

Tutanota日历功能的这一实现问题展示了在处理复杂日历事件时协议一致性的重要性。通过遵循iCalendar标准规范，可以确保不同客户端之间的互操作性。修复此问题将提升Tutanota日历功能的可靠性和用户体验，特别是在团队协作场景下。