Present single-Session migration through follow redirection
单会话迁移通过 follow 重定向呈现
Opening historical Sessions can wait for lengthy format conversion. Ordinary loading cannot explain the current phase or show migration failure; placing progress inside history events would contaminate the model log and change journal sequence semantics.
English
Problem
Opening historical Sessions can wait for lengthy format conversion. Ordinary loading cannot explain the current phase or show migration failure; placing progress inside history events would contaminate the model log and change journal sequence semantics.
Proposal
Add a typed business redirect to single-Session history reads: page or follow returns a migration reference when preparation is required, the Client follows that migration for its current phase and subsequent progress, then returns to the original history read after success. “302” denotes a business result, not a browser HTTP redirect, and accepts no arbitrary URL.
The Session object layer owns redirection, waiting, failure, and reopening. React must observe an explicit migration state and render a dedicated component; failure retains its cause and retry action. Migration success returns only to history loading, and a valid snapshot establishes history readiness. Paging and reconnect retain existing history and drafts.
The actual persistence preparation owner retains migration ownership; multiple waiters share work and late joiners receive current state immediately. Closing one view releases only its waiter. Started durable publication retains its run-to-settlement policy. Progress enters neither the Session log nor session.control for this flow.
Create/adopt and full-text search keep automatic processing; fork and catalog reads use the migration prerequisite.
Completion milestone remains open
Read-open currently produces validated in-memory history; write-open encodes, verifies, and publishes a new generation. If redirection waits only for read preparation, its reference must retain the prepared result until the original follow takes ownership rather than relying on an evictable short-lived cache. Waiting for publication instead adds write-permission and publication-time requirements to opening old history. Implementation must choose this behavior rather than using an ambiguous done state for both milestones.
Alternatives considered
Push migration progress through global control. One history-opening operation can own its waiting, failure, and retry without independent global progress synchronization.
Insert progress before the ordinary history journal's opening frame. The generic journal remains snapshot-first; the Session adapter consumes redirection and migration frames, forwarding only ordinary history to the journal.
Automatically replay every RPC that encounters migration. Commands with committed effects cannot be replayed safely. This proposal covers recoverable history reads rather than a general command-retry platform.
Acceptance criteria
- The Client shows actual migration phases before receiving the history snapshot; failure remains visible without an automatic retry loop.
- Concurrent joiners, independent waiter cancellation, and reconnect observe the same operation's current state; an old attempt cannot overwrite a new one.
- The resumed history read cannot restart the same migration after cache eviction; cancellation never rolls back a published generation.
- Unknown totals produce no fabricated percentages. Unrelated lightweight requests and progress frames receive execution time during migration, with responsiveness measured separately.
- Create/search, fork/catalog policies, and existing Session data retain their respective guarantees.
Risks
Redirection spans two requests and needs explicit retention and cancellation ownership. Progress alone does not remove synchronous Host parsing and validation stalls; scheduling changes require measurements. The choice between read preparation and write publication remains an implementation prerequisite.
中文
问题
打开历史会话可能等待较长的格式转换。普通 loading 无法解释当前阶段或显示迁移失败；把进度放入历史事件又会污染模型日志，并改变历史流的序号语义。
提案
对单会话历史读取增加 typed 业务重定向：page 或 follow 在需要迁移时返回迁移引用，Client 转到迁移 follow，接收当前阶段和后续进度；成功后回到原历史读取。这里的“302”是业务结果，不是浏览器 HTTP 跳转，也不接受任意 URL。
Session 对象层编排跳转、等待、失败和重新读取。React 必须看到迁移中的明确状态并显示专门组件；失败保留原因和重试入口。迁移成功只回到历史加载态，收到有效 snapshot 才表示历史就绪。分页或重连已经拥有的历史与草稿保留。
迁移操作仍由实际持久化准备入口拥有；多个等待者共享任务，后加入者立即取得当前状态。关闭一个视图只释放其等待，不取消其他等待者。已开始的 durable publication 遵守既有运行至结算规则。进度不写入 Session log，不使用 session.control 作为本流程的进度通道。
create/adopt 和全文搜索保持自动处理；fork 和目录读取采用迁移前置检查。
完成里程碑仍待确定
现有 read-open 只生成经验证的内存结果；write-open 才编码、校验并发布新 generation。若重定向只等待读准备，迁移引用必须将准备结果保留到原 follow 接手，不能依赖可淘汰的短期缓存。若等待完整发布，则打开旧历史会额外要求写权限并等待发布。实现前必须确定这一行为，不以一个模糊的 done 混用两种里程碑。
考虑过的替代方案
通过全局 control 推送迁移进度。 单次打开历史的等待、错误与重试更适合由该读取流程拥有，不需要增加独立的全局进度状态同步。
直接在普通 history journal 首帧前插入进度。 通用 journal 保持 snapshot-first；Session 适配层消费重定向和迁移流，只把正常历史交给 journal。
所有 RPC 遇到迁移都自动重发。 已执行副作用的命令不能安全重放。此提案限定可安全恢复的历史读取，不扩展成通用命令重试平台。
验收条件
- 迁移等待开始后，Client 在收到历史 snapshot 前显示真实阶段；失败保持可见且不会自动循环重试。
- 并发加入、单等待者取消和重连均取得同一操作的当前状态；旧尝试的通知不覆盖新尝试。
- 完成后的历史读取不会因为缓存淘汰重新启动同一迁移；已发布 generation 不因取消而回滚。
- 未知总量不显示伪造百分比。迁移时无关轻量请求和进度帧仍能得到执行机会，响应性单独测量。
- create/search、fork/catalog 策略及已有 Session 数据保持各自约定。
风险
重定向跨越两次请求，需要明确保活与取消所有权。迁移进度并不会消除 Host 主线程的同步解析和验证暂停；相关调度调整必须依据实测。只读准备与写入发布的完成定义仍是实施前置选择。