封存入口闭环：实例级窗口接线 + 独立目标同步/恢复（0.1.180） #11
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Weknora/knowledge-governance#11
Reference in New Issue
Block a user
Delete Branch "feat/library-capture-instance-window"
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?
做了什么
封存入口接线（不再用库级窗口跑实例）
libraryctl capture/recover改由librarymaintenance.Manager装配：入口闸门、后台静默检查、目标指纹、入口探针与发布链路同一套实现。SIGTERM
exit=1不再等于"请求被截断"，排空证据来自闸门 drain 记录（校验没有放松，补的是缺的那层证据）。
internal/librarymaintenance/env.go（LIBRARY_TARGET_*唯一解析处），缺项在开窗口前拒绝并点名；agent 启动如实打印接线状态；安装脚本强制 0600
agent.env。-source-s3-endpoint：容器里的 minio 服务名宿主机解析不到，资源导出会失败。接线后暴露并修掉的四个真缺陷
POST /library/captures队列作业 id 45 字符 >jobs.id varchar(36)→ 一律 500；tenant_id，只按 term 过滤 → 导出 0 条、候选校验报 legacy coverage；{}映射）被当成"索引被改坏" → 首次同步失败；.→ 维护窗口invalid freeze request。另外：同步资源行时定位符里的桶要从来源桶换到目标桶（否则目标取不到图/附件），换桶变换写入与校验共用。
真实验收（本机专用实例，未动共享栈/远程生产）
conn:open active=1）→ 再发起封存 → 入口关闭 → 补完正文 → 应用 200；drain.json phase=drained active_at_close=1 served=126，quiesce.samples=18 stable_ms=1617。1196c518…（撤销后 KB：9 Wiki 页 / 1 文档 / 2 分块 / 1 资源），与源逐页比对一致。libsync-internal-1793226278273693890succeeded + verify succeeded。librestore-internal-1793226571284097366-retrysucceeded，逐项读回与快照一致。graph_enabled=true→ CLI 预检 exit 1Neo4j graph snapshot is not supported。CI：最终 HEAD 之前每个代码提交都有 run；211 failure（密钥扫描误报，下一提交修）、215 failure（gofmt）、
218 cancelled（被后续提交取消）如实保留，其余 success。
make verify15 项全绿。详见交付报告
release-capture-close-loop-result.md（本机 handoffs）。全新 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 全绿。View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.