Kiwi Raft Apply Correctness：父 Issue 与子 Issue 拆分方案

[AlexStocks]

# Kiwi Raft Apply Correctness：父 Issue 与子 Issue 拆分方案

状态：核心恢复模型已确认，剩余通用约束与 PR 边界待 Review
最近更新：2026-07-17（确认两级恢复、target-instance ApplyMarkerCF、typed outcome 与 cluster FLUSH gate）
目标：作为独立于 VectorSet 的 Kiwi 通用 Raft 正确性改造计划
计划用途：先创建父 Issue，再按本文拆分多个子 Issue 与实现 PR
非目标：本文不实现 VectorSet、FLAT、HNSW，也不修改 Redis 命令语义
下游设计：Kiwi Redis 8 Vector Set 存储设计

1. 为什么必须从 VectorSet 方案中拆出

VectorSet 依赖以下通用能力：

• RESP 写命令能够可靠进入 Raft proposal；
• committed log 只在业务数据成功提交后推进 applied state；
• RocksDB I/O 错误会停止正常 apply，而不是作为普通业务错误继续；
• 节点崩溃后能够识别“业务 batch 已提交、applied frontier 尚未持久化”的窗口，并安全重放；
• 多 RocksDB instance 下，slot、instance、mutation 和 snapshot frontier 保持一致；
• 状态机能够返回与 RESP 解耦的 typed result 和 typed business error。

这些能力不是 VectorSet 专属。String、Hash、Set、List、ZSet、TTL、DEL 和后续新增数据类型都依赖同一套状态机正确性。FLUSHDB/FLUSHALL 因为跨多个 RocksDB instance，单独使用 cluster feature gate 管理，在 database epoch 方案完成前不进入普通 logical mutation apply。

因此：

1. 本文单独描述 Raft apply correctness；
2. VectorSet 设计只引用本文定义的能力契约；
3. 在本文除独立 cluster FLUSH gate 外的 PR0 阻断项完成前，VectorSet cluster 模式不得开放；
4. standalone VectorSet 可以独立开发，但不能用单机测试代替 Raft 正确性验证。

2. 当前源码证据

以下结论来自当前仓库源码，不是对未来实现的推测。

2.1 last_applied 在业务写入前推进

当前状态机在处理每条 entry 时，先更新内存字段：

self.last_applied = Some(entry.log_id);

然后才执行 apply_binlog()：

• src/raft/src/state_machine.rs:237-245

如果 RocksDB 写入失败，当前代码把错误转换成 BinlogResponse::error，但仍继续处理后续日志：

• src/raft/src/state_machine.rs:243-257

这不满足“只有业务状态成功提交后才能推进 applied frontier”的状态机不变量。

2.2 last_applied 目前只存在于状态机内存

KiwiStateMachine 的 last_applied 是普通内存字段：

• src/raft/src/state_machine.rs:181-188

snapshot 会携带 last log id，但普通 apply 路径没有定义 durable state machine metadata 与业务数据之间的恢复协议。

2.3 当前 Binlog 只表达物理写入

当前日志类型只有：

pub enum OperateType {
    NoOp = 0,
    Put = 1,
    Delete = 2,
}

• src/conf/src/raft_type.rs:23-29

Binlog 只包含一个 slot_idx 和一组物理 CF entry：

• src/conf/src/raft_type.rs:31-46

当前 storage apply 只支持 CF 0～5，并且没有使用传入的 _raft_log_index：

• src/storage/src/storage.rs:485-523

2.4 RESP 命令到 Raft 的执行链尚未闭环

当前 Cmd trait 暴露：

fn to_binlog(...)
fn needs_raft(...)

• src/cmd/src/lib.rs:235-241

当前只有 SET 标记 CmdFlags::RAFT 并实现 to_binlog()：

• src/cmd/src/set.rs:34-95

DEL 和 EXPIRE 仍是普通本地写命令：

• src/cmd/src/del.rs:32-78
• src/cmd/src/expire.rs:32-86

全仓搜索没有发现 RESP 命令执行路径实际调用 Cmd::to_binlog() 或 Cmd::needs_raft() 的闭环。

2.5 多 RocksDB instance checkpoint 当前依次创建

Storage::create_checkpoint() 依次为每个 RocksDB instance 创建 checkpoint：

• src/storage/src/storage.rs:407-425

当前 snapshot builder 捕获 last_applied 后直接调用该方法，没有与 state machine apply 共享构建 barrier：

• src/raft/src/state_machine.rs:427-477

3. 目标不变量

本改造完成后，必须能够证明以下不变量。

I1. Applied-after-commit

只有业务 mutation 成功提交后，日志才可被标记为 applied。

I2. Fatal errors stop apply

RocksDB、CF、日志格式、slot、checksum 或 durable metadata 错误
不能转换成普通业务失败后继续下一条日志。

I3. Business rejection is deterministic

WRONGTYPE、条件不满足、成员不存在等业务错误
可以不修改业务数据，但必须在所有副本产生相同 typed result，
并把该 committed entry 标记为已确定性处理。

I4. Crash replay is safe

如果业务 batch 已提交，但 durable global applied frontier 尚未提交，
重启后重复 apply 同一 log id 必须是确定性 no-op，且能够恢复原结果。

I5. Slot and instance are revalidated

状态机不能信任 proposal 携带的 slot_idx；
apply 必须根据 key 重新计算 slot 和 RocksDB instance。

I6. One mutation does not silently cross RocksDB instances

普通 mutation 不能把一个 RocksDB WriteBatch 伪装成跨多个独立 DB 的原子事务。

I7. Snapshot represents one applied frontier

多实例 snapshot 的所有 checkpoint 必须对应同一个 last_applied=L，
不能组合出从未在任何日志位置存在过的混合状态。

4. 已确认的目标模型

4.1 Apply 结果分类

enum ApplyOutcome {
    Applied(StateMachineResult),
    BusinessRejected(StateMachineBusinessError),
}

type ApplyResult = Result<ApplyOutcome, StateMachineFatalError>;

Applied 和 BusinessRejected 都表示该 committed entry 已被确定性处理，可以在持久化对应结果后推进 applied frontier。StateMachineFatalError 只能通过 Result::Err 返回，不能作为普通 outcome 持久化后继续下一条日志。

成功结果至少包括：

enum StateMachineResult {
    None,
    Integer(i64),
    Boolean(bool),
}

业务错误使用稳定 code，而不是把 RESP 文本直接放进 Raft 层：

enum StateMachineBusinessError {
    WrongType,
    KeyNotFound,
    ConditionNotMet,
    InvalidState,
    UnsupportedInCluster,
}

Raft 层不依赖 RespData。命令层负责把 typed result 转成 RESP2/RESP3。

持久化结果选择 bounded、versioned、RESP-independent 的 typed outcome，而不是只保存一个无法恢复成功返回值的 result code：

enum PersistedApplyOutcomeV1 {
    Applied(StateMachineResultV1),
    BusinessRejected(StateMachineBusinessErrorV1),
}

要求：

• 有独立 format_version，decoder 拒绝未知未来版本；
• 大小有硬上限，不能把任意业务 value 或无界 payload 写入 marker；
• 保存恢复相同 typed result 所需的最小信息，例如 VADD/VREM 的整数结果；
• business error 保存稳定 code 和受限的结构化 details，不保存 RESP 文本；
• RESP2/RESP3 编码、错误文案和客户端协议仍由命令层决定。

4.2 ApplyContext

所有 logical mutation apply 接收统一上下文：

struct ApplyContext {
    log_id: LogId,
    slot_id: u32,
    db_id: u32,
    leader_time_ms: Option<u64>,
    mutation_format_version: u16,
}

其中 leader_time_ms 只用于需要确定性时间输入的 mutation，例如相对 TTL 转绝对 TTL 后的校验；状态机不能自行用本地当前时间决定副本相关的业务分支。

4.3 目标 instance 内的 apply marker

由于 Kiwi 使用多个独立 RocksDB instance，全局 last_applied 无法天然与任意目标 instance 的业务数据放入同一个 WriteBatch。

每个 RocksDB instance 新增内部 ApplyMarkerCF。每条 mutation 在目标 instance 的同一个 WriteBatch 中写入：

业务状态变更
+
ApplyMarkerCF[log_id] = persisted outcome / mutation digest

记录：

struct AppliedMutationRecordV1 {
    format_version: u16,
    log_id: LogId,
    mutation_digest: [u8; 32],
    outcome: PersistedApplyOutcome,
}

要求：

• 同一 log id、同一 digest 重放：返回已保存结果，不重复修改数据；
• 同一 log id、不同 digest：视为日志或数据损坏，停止 apply；
• business rejection 也必须记录；
• apply marker 在 snapshot 安全覆盖对应日志后才能清理。

ApplyMarkerCF 必须位于目标业务 RocksDB instance，不能用独立 Raft state store 代替，因为后者无法与业务 mutation 组成同一个 RocksDB WriteBatch。独立 Raft state store 只保存 durable global frontier、membership 和 snapshot metadata。

4.4 Durable global applied frontier

全局状态机 metadata 至少包含：

struct DurableStateMachineMeta {
    format_version: u16,
    last_applied: Option<LogId>,
    last_membership: StoredMembership,
}

提交顺序必须是：

1. 目标 instance：业务 mutation + apply marker，原子 commit
2. durable global applied frontier
3. 返回 typed result

禁止：

先提交 global last_applied，再提交业务数据

允许的崩溃窗口是：

业务数据和 apply marker 已提交，global last_applied 尚未提交

重启后通过 apply marker 安全重放并补齐 global frontier。

5. 父 Issue 草案

标题

feat(raft): establish crash-safe state machine apply semantics

背景

Kiwi 当前 OpenRaft state machine 在业务写入前更新内存 last_applied，并把 storage apply 错误包装成普通 BinlogResponse 后继续处理后续日志。同时，RESP 命令到 Raft proposal 的通用执行链、durable applied frontier、多 RocksDB instance 下的 crash replay 协议和 typed business result 尚未形成闭环。

这些问题会影响所有需要跨 CF 原子 mutation、状态相关返回值、TTL 和多实例 snapshot 的数据类型。VectorSet 只是第一个集中暴露这些基础能力缺口的复杂类型，因此本 Issue 独立于 VectorSet 跟踪。

目标

• 建立业务 commit 成功后才能推进 applied frontier 的顺序；
• 区分 deterministic business rejection 与 fatal storage/protocol error；
• 持久化 state machine applied state；
• 支持 crash window 下的幂等 replay 和结果恢复；
• 闭环 RESP command → Raft proposal → state machine apply → typed response；
• 在 apply 阶段重新验证 slot 和 RocksDB instance；
• 让多实例 snapshot 对应单一 applied frontier；
• 用故障注入和三节点测试证明上述不变量。

非目标

• 不实现 Redis Vector Set；
• 不实现 FLAT/HNSW；
• 不在本 Issue 内完成所有 Redis 命令的 Raft 化；
• 不在本 Issue 内实现 database epoch，也不开放 cluster FLUSHDB/FLUSHALL；
• 不引入跨多个独立 RocksDB instance 的通用分布式事务；
• 不以降低 RocksDB durability 或跳过失败日志换取测试通过。

完成标准

• last_applied 不在业务 commit 前推进；
• fatal apply error 会使状态机停止正常 apply；
• durable state machine metadata 可在重启后恢复；
• 目标 instance 的业务数据与 apply marker 原子提交；
• 同一 log id 重放不会重复修改业务数据；
• 同一 log id、不同 mutation 会被识别为损坏；
• business rejection 能恢复相同 typed result；
• persisted outcome 是 bounded、versioned、RESP-independent；
• RESP 写命令存在真实 Raft proposal 调用链；
• apply 重新计算并验证 slot/instance；
• 多实例 snapshot 证明对应同一 applied frontier；
• 三节点 crash/failover/snapshot replay 测试通过；
• Linux 集成测试与全平台构建通过。

6. 子 Issue 拆分

子 Issue 1：修正 apply 顺序与 fatal error 传播

建议标题：

fix(raft): advance applied state only after successful storage commit

范围：

• 调整 KiwiStateMachine::apply() 顺序；
• storage/protocol corruption 返回 OpenRaft StorageError；
• business rejection 与 fatal error 分离；
• fatal error 后不得继续消费后续 entry；
• 增加 apply 顺序和错误分类单测。

验收：

• commit 失败时 last_applied 不推进；
• 下一条日志不被继续 apply；
• business rejection 仍能作为已处理 entry 推进；
• 错误日志包含 log id、slot、instance 和 mutation type，但不泄露敏感 value。

子 Issue 2：持久化 state machine metadata

建议标题：

feat(raft): persist and recover state machine applied metadata

范围：

• 定义 DurableStateMachineMeta format；
• 持久化 last_applied 和 membership；
• 启动时恢复；
• 校验 snapshot metadata、Raft log store 和 state machine metadata 的关系；
• 拒绝不支持的未来 format version。

验收：

• 正常重启后恢复正确 last_applied；
• metadata 损坏时拒绝继续提供强一致服务；
• snapshot install 后 metadata 与 snapshot last log id 一致；
• 不依赖内存默认值猜测恢复位置。

子 Issue 3：实现 per-log apply marker 与结果重放

建议标题：

feat(raft): add per-log apply markers for crash-safe replay

范围：

• 在每个目标 RocksDB instance 新增内部 ApplyMarkerCF；
• marker 与目标 instance 业务 mutation 同 batch；
• 保存 mutation digest 和 bounded/versioned/RESP-independent typed outcome；
• 重放时恢复原结果；
• snapshot 后安全清理旧 marker。

验收：

• 业务 batch 后、global frontier 前崩溃可安全恢复；
• 重放不重复增减 count；
• business rejection 重放返回相同 error code；
• VADD/VREM 等成功返回值可从 persisted typed outcome 精确恢复；
• 超过 outcome 大小上限的 mutation 在提交业务 batch 前失败；
• 相同 log id、不同 digest 会停止 apply；
• marker 清理不会破坏 snapshot + replay。

子 Issue 4：闭环 RESP 命令到 Raft proposal 和 typed response

建议标题：

feat(raft): route raft-enabled RESP writes through state machine proposals

范围：

• 为 CmdFlags::RAFT 和 Cmd::to_binlog() 建立实际调用方，或用统一 logical mutation API 替代；
• cluster 模式禁止本地先写后 proposal；
• follower 写请求 redirect/proxy 行为明确；
• typed result 转 RESP2/RESP3；
• 保留 standalone 与 cluster 共用业务 mutation 的接口边界。

验收：

• raft-enabled 命令不直接调用本地写路径；
• leader 的权威写只发生在 state machine apply；
• follower 不本地执行权威写；
• proposer 在 commit/apply 完成前不返回成功；
• typed business error 能正确转换成 RESP error。

子 Issue 5：强化 slot 与多 RocksDB instance apply 不变量

建议标题：

fix(raft): validate mutation slots and RocksDB instance routing during apply

范围：

• apply 根据 key 重新计算 slot；
• 校验 proposal slot；
• 校验目标 RocksDB instance；
• 定义多 key 同 slot 规则；
• 禁止普通 mutation 静默跨 instance；
• 为特殊全局 mutation 预留独立类型，不伪装成单 slot Binlog。

验收：

• slot 不匹配会停止 apply；
• element/member 不能改变 key 的 instance 路由；
• cluster 多 key 跨 slot 返回确定性错误；
• 至少 3 个 RocksDB instance 的路由测试通过；
• snapshot/restore 后相同 key 仍映射到相同 instance。

子 Issue 6：定义 TTL 与通用 key 生命周期的确定性 mutation 契约

建议标题：

feat(raft): define deterministic TTL and key lifecycle mutations

范围：

• relative TTL 在 leader 侧转成绝对 expire time；
• apply 不使用各副本本地当前时间决定业务分支；
• 区分逻辑过期与物理清理；
• 定义 DEL、EXPIRE/PEXPIRE/EXPIREAT、PERSIST 的 logical mutation；
• cluster FLUSHDB/FLUSHALL 在 proposal 前返回稳定的 UnsupportedInCluster，不得退化为本地物理 flush；
• database epoch 是后续全局 FLUSH 语义的优先方向，单独设计 epoch 持久化、可见性、snapshot、compaction、迁移和混版本门禁；
• 明确跨 slot、多 instance 命令限制。

验收：

• 三节点对同一 TTL mutation 保存相同 expire time；
• 时钟偏差不会使 apply 的业务结果分叉；
• 后台清理不产生未复制的逻辑状态变化；
• DEL/EXPIRE/PERSIST 不绕过 Raft；
• cluster FLUSHDB/FLUSHALL 在独立 feature gate 打开前确定性拒绝，且不修改任何 instance；
• leader failover 后逻辑过期行为可预测。

子 Issue 7：建立多实例 snapshot build barrier 与 replay 契约

建议标题：

fix(raft): build multi-instance snapshots at one applied frontier

范围：

• snapshot builder 与 state machine apply 使用同一 barrier；
• 等待 in-flight apply；
• 捕获 last_applied=L；
• 依次或安全并行创建所有 instance checkpoint；
• 所有 checkpoint 和 manifest 成功后才发布 snapshot；
• barrier 释放后再进行可异步的打包和传输；
• 所有失败路径恢复 apply 并删除未发布的临时 snapshot。

验收：

• 所有 instance checkpoint 对应相同 L；
• 任一 instance checkpoint 失败不会发布部分 snapshot；
• manifest 写失败会恢复 apply；
• snapshot install + L+1 日志重放结果正确；
• snapshot build 期间并发写入不会形成混合 frontier；
• 记录 barrier 时间、checkpoint 时间和失败指标。

子 Issue 8：补齐故障注入、三节点恢复与可观测性

建议标题：

test(raft): cover crash windows and multi-instance state machine recovery

范围：

• 为业务 batch、apply marker、global frontier、snapshot checkpoint、manifest、restore 增加故障注入点；
• 三节点 leader failover；
• 多 instance 连续路由；
• snapshot + replay；
• unhealthy/fatal 状态指标和日志。

验收测试至少覆盖：

1. commit 前崩溃；
2. 业务 batch 后、global frontier 前崩溃；
3. global frontier 后、客户端回复前崩溃；
4. RocksDB commit 失败；
5. business rejection；
6. 相同 log id 相同 mutation 重放；
7. 相同 log id 不同 mutation；
8. leader failover；
9. 三个 RocksDB instance 轮流写入；
10. snapshot install + log replay；
11. 某个 instance checkpoint 失败；
12. snapshot manifest 或 restore 中断。

7. 子 Issue 依赖关系

子 Issue 1：apply 顺序与 fatal error
  |
  +--> 子 Issue 2：durable state machine metadata
  |      |
  |      +--> 子 Issue 3：apply marker 与结果重放
  |
  +--> 子 Issue 4：RESP -> Raft -> typed response

子 Issue 3 + 子 Issue 4
  |
  +--> 子 Issue 5：slot / multi-instance 不变量
         |
         +--> 子 Issue 6：TTL / key lifecycle
         +--> 子 Issue 7：snapshot frontier / replay

子 Issue 1～7
  |
  +--> 子 Issue 8：故障注入与三节点验收

允许并行：

• 子 Issue 2 与子 Issue 4 可以在子 Issue 1 的接口冻结后并行；
• 子 Issue 6 与子 Issue 7 可以在子 Issue 3、5 完成后并行；
• 子 Issue 8 的测试框架可以提前搭建，但最终验收必须等待其他子 Issue。

8. 建议的实现 PR 分组

不建议机械地做到“一子 Issue 一个 PR”。可以按可验证边界分组：

PR0-A：Apply error semantics

覆盖子 Issue 1：

• apply 顺序；
• fatal/business 分类；
• OpenRaft error 传播；
• 基础单测。

PR0-B：Durable recovery

覆盖子 Issue 2、3：

• durable state machine metadata；
• apply marker；
• mutation digest；
• crash replay。

PR0-C：Command routing and deterministic mutations

覆盖子 Issue 4、5、6：

• RESP→Raft 接线；
• typed response；
• slot/instance 校验；
• TTL/key lifecycle 契约。

PR0-D：Snapshot and fault-injection gates

覆盖子 Issue 7、8：

• multi-instance snapshot barrier；
• restore/replay；
• 三节点故障注入；
• 指标和运维说明。

9. VectorSet 可以依赖的 PR0 能力契约

VectorSet 设计不需要重复实现本文件内部机制，只依赖以下稳定接口。

9.1 写入接口

async fn propose_logical_mutation(
    mutation: LogicalMutation,
) -> Result<StateMachineResult, StateMachineBusinessError>;

保证：

• cluster 写只在 state machine apply 修改权威数据；
• 成功返回时 quorum commit、apply 和 durable frontier 已完成；
• 重试不会重复执行 mutation；
• fatal error 不伪装成业务失败。

9.2 Apply 接口

fn apply_logical_mutation(
    mutation: &LogicalMutation,
    ctx: &ApplyContext,
) -> Result<ApplyOutcome, StateMachineFatalError>;

保证：

• 提供稳定 log id、slot、db id 和确定性时间输入；
• target instance 路由已经校验；
• mutation 可在目标 instance 内构造原子 WriteBatch；
• apply marker 和结果重放由通用层负责；
• marker 位于 target instance 的内部 ApplyMarkerCF；
• persisted outcome 是 bounded、versioned、RESP-independent 的 typed outcome。

FLUSHDB/FLUSHALL 不使用该接口，直到独立的 database epoch 设计与 cluster feature gate 验收完成。

9.3 读屏障

leader linearizable barrier
  -> 等待 local applied >= barrier
  -> 读取 RocksDB snapshot

VectorSet 只负责从同一个 RocksDB snapshot 读取 MetaCF 和 VectorDataCF。

9.4 Snapshot 契约

VectorSet 不自行协调多个 RocksDB instance checkpoint；
通用 Raft snapshot 层保证 snapshot 对应单一 applied frontier。

VectorSet 只负责：

• 在 snapshot schema manifest 中声明新增 CF 和 value format；
• 保留并校验 VectorDataCF key 所依赖的 storage_incarnation；
• 在 restore 时校验 VectorSet schema；
• 不把 Phase 2 HNSW 派生索引当作权威 snapshot 数据。

10. VectorSet 与 PR0 的边界

VectorSet 一侧的完整存储、命令和索引设计见 Kiwi Redis 8 Vector Set 存储设计。两篇文档以本节和第 9 节的能力契约为唯一衔接点，不在各自文档中复制另一侧的内部实现。

属于 PR0：

• Raft apply 顺序；
• durable applied state；
• apply marker；
• typed state machine result；
• RESP command 到 proposal 的通用链路；
• slot/instance 二次校验；
• TTL 的确定性时间输入；
• cluster FLUSHDB/FLUSHALL 的显式禁用门禁；
• 多实例 snapshot frontier；
• crash/failover 测试框架。

属于 VectorSet：

• Redis 8 VADD/VSIM/VREM/VCARD/VDIM/VEMB/VISMEMBER/VINFO；
• VectorSet MetaCF reserve 格式；
• VectorDataCF key/value codec；
• normalized FP32 + original L2；
• FLAT bounded top-K；
• VectorSet O(1) DEL 和 compaction；
• storage incarnation、VectorSet generation 和 data revision；
• Phase 2 HNSW 派生索引；
• VectorSet differential、性能和资源限制测试。

11. 父 Issue 关闭门禁

父 Issue 只有在以下条件全部满足后才能关闭：

• 所有子 Issue 已关闭或有明确、无正确性风险的后续 Issue；
• PR0-A～PR0-D 已合入；
• 当前 Head 上重新执行完整 Raft 相关测试；
• 三节点 failover、crash replay、snapshot restore 测试通过；
• 至少 3 个 RocksDB instance 的测试通过；
• cargo fmt --check 通过；
• 项目 clippy 门禁通过；
• Linux 环境测试通过；
• 没有未解决的 P0/P1 Raft apply correctness finding；
• VectorSet cluster feature gate 仍保持关闭，直到 VectorSet 自身的 cluster 测试完成。
• cluster FLUSHDB/FLUSHALL feature gate 保持关闭，并验证命令在 proposal 前确定性拒绝且不修改任何 instance。

12. 明天创建 Issue 时的建议顺序

1. 先创建本文第 5 节父 Issue；
2. 创建第 6 节的八个子 Issue；
3. 在父 Issue 中维护 checklist 和依赖图；
4. 每个子 Issue 链接对应源码证据，不复制未经验证的实现结论；
5. 先安排子 Issue 1，冻结错误分类和 apply 顺序；
6. 再并行推进 durable metadata 与 command routing；
7. 最后用 fault-injection 子 Issue 做统一验收；
8. PR0 父 Issue 关闭前，不在 cluster 模式开放 VectorSet。
9. 单独创建 Raft Global Flush Semantics 后续 Issue，以 database epoch 为优先方向；该 Issue 完成前不开放 cluster FLUSHDB/FLUSHALL。

13. 关键决策状态

13.1 已确认

• 接受“目标 instance apply marker + durable global frontier”的两级恢复模型；
• apply marker 使用目标 RocksDB instance 内的新内部 ApplyMarkerCF，不使用独立 Raft state store 代替；
• persisted outcome 保存 bounded、versioned、RESP-independent 的 typed outcome；
• FLUSHDB/FLUSHALL 的优先方向是 database epoch；在独立设计和验收完成前，cluster feature gate 保持关闭并确定性拒绝命令。

13.2 仍待确认

• relative TTL 是否统一在 leader proposal 前转成绝对时间；
• cluster 多 key 命令是否统一执行 Redis Cluster same-slot 约束；
• snapshot barrier 释放点是否固定在所有 checkpoint + manifest 成功之后；
• PR0-A～PR0-D 是否作为建议 PR 边界。

剩余决策应在父 Issue Review 阶段确认，不能留到各子 PR 中分别作出互相冲突的选择。前三项属于正确性/兼容性约束，最后一项属于交付边界，不改变已确认的恢复模型。

[AlexStocks]

P0 Raft Apply Correctness Issue 树

已根据本 Discussion 的父/子 Issue 方案创建 GitHub Issues：

• Parent：#332 feat(raft): establish crash-safe state machine apply semantics
  • #333 fix(raft): advance applied state only after successful storage commit
  • #334 feat(raft): persist and recover state machine applied metadata
  • #335 feat(raft): add per-log apply markers for crash-safe replay
  • #336 feat(raft): route raft-enabled RESP writes through state machine proposals
  • #337 fix(raft): validate mutation slots and RocksDB instance routing during apply
  • #338 feat(raft): define deterministic TTL and key lifecycle mutations
  • #339 fix(raft): build multi-instance snapshots at one applied frontier
  • #340 test(raft): cover crash windows and multi-instance state machine recovery

执行顺序：先 #333；接口冻结后 #334 与 #336 可并行；随后 #335、#337；再推进 #338/#339；#340 测试框架可提前开始，但最终验收依赖 #333～#339。

所有 Issue 均带 P0 label，并链接本 Discussion 与下游 VectorSet Discussion #331。