发布管理：执行器可用性来自真实观测、整库还原入口与脱敏诊断 #12
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Weknora/knowledge-governance#12
Reference in New Issue
Block a user
Delete Branch "feat/library-executor-availability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
已实现
health、迁移 074library_executor_status、30s 心跳）；overview / 快照列表 / POST captures 共用同一判定与原因。agent_identity复核；不一致不登记测试封存。GET /library/restore-availability+ 页面恢复入口（管理员签发 30 分钟 restore 授权，条件满足才可点）。internal/pgdsn（按口令与形状脱敏，保留 Unwrap）。边界
真实验证
候选隔离栈：停候选 agent → overview
capture_available=false（原因“不可达”）→ POST captures 503library_capture_unavailable→ 启 agent 恢复 true；restore-availability200。证据在$TMPDIR/kg-candidate-verify/evidence/。尚未验证
真实封存（会产生新快照/停写入者窗口）与真实恢复作业未在新构建上重跑；正式 8088 未部署；正式 release-worker 配置修正需部署窗口。
未部署。
全新 WeKnora 会用空映射（{}）先建好索引，范围字段等第一次写入才动态生成。 首次同步在读目标当前状态时就报 "missing release scope fields" 并失败，等于 "往空的生产实例做第一次同步"这条路根本走不通。 现在："没有范围字段 + 索引确实 0 篇文档" = 空基线；有文档却看不出归属仍然报错 （绝不把无法归属的文档当空库覆盖）。Count 与整库导出共用同一判断。 试过：make verify 15 项全绿；新增空/非空两种索引的用例；真实 sync 复现原错误。上游 task_dead_letters 没有解决标记，purge/DELETE 会销毁"失败过"的唯一证据。 治理侧新增解除记录（迁移 073）：绑定实时行逐字节指纹、重放引用、源侧观测摘要与 操作人；行被改过、重放后又出现新死信、源侧未结清都不命中，封存照旧阻断。 指纹先压紧空白再摘要，避免 PG to_jsonb::text 与 json.Marshal 的空白差异。 试过：go test ./internal/{librarydeadletter,libraryagent,httpapi,releaseadapter/v071, platform/postgres}，make verify 15 项全绿。storage://<id> 是来源实例 storage_backends 的主键；只换桶不改 id 时，目标原版 应用以 storage backend not found 落回默认服务并拒绝整条路径（真实下载 500 code1007）。写入前按租户+目标桶解析目标后端，写入与校验共用同一份行变换； 解析不到就拒绝写入，不再产出目标读不出来的定位符。 试过：目标实例真实同步后 /api/v1/knowledge/{id}/download 读回 500 → 修后复测； go test ./internal/releaseadapter/v071 与 make verify 15 项全绿。原版应用先按 resources.storage_backend_id 找文件服务；只改定位符不改这一列， 目标仍报 storage backend not found 并拒绝整条路径（真实下载 500 code1007）。 行变换同时改写该列，写入与校验共用。 试过：目标同步后 /api/v1/knowledge/{id}/download 500 → 修后复测读回 507B 且 sha256 与源对象一致；go test ./internal/releaseadapter/v071 与 make verify 全绿。同步目标与封存源常常不是同一个实例（kgseal vs kgmaint）；用目标名去绑来源死信， 真实观测的 project 永远对不上，解除会被一律拒绝。新增 LIBRARY_SOURCE_INSTANCE， 留空回落到目标实例名，API 写记录与 worker 取指纹共用同一个来源实例名。 试过：真实 API GET/POST、go test ./internal/{httpapi,appconfig} 与 make verify 全绿。页面上的"可发起封存"原来只判 LIBRARY_AGENT_SOCKET 非空：正式栈的 API 根本没挂 那个 socket，而 agent 曾顶着正式单元名冻结候选实例——配置非空、页面可点、真发起 却封错库。 现在：agent 新增 health 动作（不占封存操作锁、不跑子进程，只回答身份/降级/忙）， worker 每 30 秒探测并写入迁移 074 的 library_executor_status；overview、快照列表与 POST /library/captures 共用同一份判定（过期、不可达、实例不符、降级、正忙都拒绝并 给原因）。封存结果由 agent 附上自报身份，worker 在停写入者之前再探测一次、执行后 用结果复核，不一致就不登记测试封存——心跳只能证明"刚才"。 期望身份用 LIBRARY_SOURCE_*（封存源），不是 LIBRARY_TARGET_*（同步目标），否则 正确的执行器会被判成不匹配。另加 GET /library/restore-availability：恢复能否执行由 双闸、该快照的恢复授权与实例维护状态决定，页面不再写死 disabled。 真跑（候选隔离栈，两处 socket 隔离不变）：overview 返回 executor {kgmaint-weknora/kgmaint-app}；停 agent 后转不可达并 503 带原因；重启后恢复。View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.