本文讨论了共享会话系统中中继（relay）向新成员推送状态时的位置同步问题。当新成员加入时，中继推送的是它最后收到的源端命令的回放，该命令可能已经发生数分钟，因此其中的位置字段是过时的。如果直接应用该位置，新成员会从开头开始，而其他成员已经进行了数分钟。正确的加入序列包含两个步骤：先应用推送状态以立即显示内容，再向中继请求实际的会话位置，请求返回后会覆盖旧位置。
主要能力与使用方式：
- 在加入会话时，通过添加一个状态同步请求（如调用 repository.requestSync()）来获取实时位置。
- 强调请求的幂等性，因为协议层和应用层都可能触发请求，重复请求成本低，但缺失请求会导致新成员丢失整个会话。
- 请求应附加在状态转换（transition）上，而不是每次发射（emission），避免变成持续轮询。
- 处理请求返回的队列信息，确保不仅同步位置，还同步当前项目之后的队列。
- 注意去重键必须包含回复可能改变的所有字段，尤其是位置字段，否则回复可能被丢弃。
- 区分推送状态为空的情况：若源端尚未发布任何命令，中继无内容可推，请求也无返回。解决方法在源端：在承担角色时及成员到达时发布快照。
- 不要阻塞加入流程等待同步回复，应先显示推送状态再校正。
- 同步回复到达后，需应用相同的飞行时间校正和寻道容差。
适用场景：
- 基于 Kotlin 的中继式共享会话应用，如协作播放、实时同步场景。
- 任何需要新成员或重新连接的跟随者快速追上当前会话状态的系统。
限制与陷阱：
- 不得根据时间戳外推过时位置，因为暂停、寻道或切换项目会导致错误且静默。
- 请求逻辑容易被埋没在其他收集器中，建议单独收集器或日志命名。
- 队列缺失表示“无变化”而非“空”，清除会丢失刚收到的状态。
- 验证方法包括：检查所有请求触发点、确认同步词汇存在、使用两个客户端进行行为测试（如运行数分钟后加入、源端无命令时加入、网络断开后恢复）。