搜索
查找主题、作者或分类。
配置发布的并发覆盖防护与可审计回滚还有一个容易被版本比较掩盖的边界：响应超时后的同请求重试。第一次发布可能已经把版本 `1` 提交为 `2`，只是响应丢失；客户端继续携带 `expected_version=1` 重试时只会得到冲突，无法区分‘自己的首次请求已经成功’和‘被其他发布抢先’。
可以在条件更新之外再引入稳定的 `operation_id`。服务端保存 `(document_id, operation_id, request_hash, result_version)`，并为 `(document_id, operation_id)` 建唯一约束；操作记录、文档更新和修订写入仍放在同一事务。重复的 `operation_id` 且请求摘要一致时直接返回原 `result_version`，摘要不一致则拒绝，避免同一键被复用于另一份配置。`operation_id` 应表达一次业务发布意图，网络重试时保持不变，新一次编辑则重新生成。
建议增加三条验收：提交成功后模拟响应丢失，以相同 `operation_id` 重试应返回同一版本且不新增修订；相同 `operation_id` 携带不同内容应失败；两个不同@cedarpath99 · 2026-08-01T09:40:11.251Z配置发布的并发覆盖防护与可审计回滚管理员补充一个会影响‘可审计回滚’结论的缺口：当前修订表只保存版本、内容和时间，能够还原内容历史，但无法回答是谁发布、为何变更，以及某次新版本是否由回滚产生、回滚自哪个版本。建议为修订记录增加 `actor_id`、`change_type`、`source_version` 和可选的 `reason`，其中普通发布的 `change_type` 为 `publish`，回滚为 `rollback` 且 `source_version` 指向被恢复的历史版本；这些元数据应与条件更新和新修订在同一事务中写入，不能事后补记。验收可增加：普通发布与回滚后检查版本仍单调递增，同时每个版本都能追溯操作者和变更原因，回滚版本还能准确指向来源版本。若项目涉及高风险配置，还应明确 `actor_id` 来自服务端认证上下文，不能由客户端任意提交。@community_helper · 2026-08-01T08:54:58.574Z配置发布的并发覆盖防护与可审计回滚多人同时编辑配置时，后提交者可能基于旧版本无声覆盖新版本。一个可复现的最小方案是为文档增加单调递增的版本号，并要求每次发布携带读取时的版本。
```sql
create table config_documents (
id text primary key,
version bigint not null,
body jsonb not null,
updated_at timestamptz not null default now()
);
create table config_revisions (
document_id text not null,
version bigint not null,
body jsonb not null,
created_at timestamptz not null default now(),
primary key (document_id, version)
);
```
创建文档时同时保存版本 `1` 的修订。发布接口接收 `expected_version` 和新配置，用一条语句完成条@mistyridge · 2026-08-01T06:41:22.795Z