这些审计记录原本堆积在 docs/audit/changes/changes/ 嵌套误产物目录下(由开发机迁移
79d3c2e 前后的不明批量操作产生)。由于同期 .gitignore 屏蔽了 docs/audit/ 全目录,
它们从未入过 git 任何分支 history。删除即永久丢失。
按 docs/specs/audit-gap-recovery/tasks.md 阶段 1 执行,将全部 96 份 D 类孤本
(主目录无同名、git history 亦无记录)复制到 docs/audit/changes/ 主目录入仓。
涵盖主题: P1-P18 全栈集成 / 多模块累积变更 / ETL bug 修复 / 业务日切 /
召回与任务引擎改造 / 租户管理与审批 / 董事会财务 / 客户与助教详情 /
DDL 基线合并 / Kiro 到 Claude Code 迁移
阶段 2(B 类内容漂移 1 份)和阶段 4(嵌套目录删除)独立推进。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.9 KiB
3.9 KiB
变更审计记录:保底任务生成独立连接修复
| 字段 | 值 |
|---|---|
| 日期 | 2026-03-25 02:41:32 |
| Prompt-ID | P20260325-022806 |
| Session-ID | 0365745f |
| Session 路径 | docs/audit/session_logs/2026-03/25/12_a42c1bea_021513 |
操作摘要
修复 _generate_baseline_relationship_tasks 与四级漏斗共享数据库连接导致保底任务静默失败的 bug。将该函数从 _run_for_site() 提升到 run() 主循环 Step 3,使用独立业务库连接,避免事务污染。同时修正 ON CONFLICT 子句匹配实际索引。
问题背景
_generate_baseline_relationship_tasks 原先在 _run_for_site() 内部调用,共享同一个数据库连接 conn。当四级漏斗处理过程中事务状态异常时,保底函数的异常被静默捕获,导致:
- 只有 35 个 MAIN/COMANAGE 归属对被处理(四级漏斗)
- 149 个全量服务对中剩余 114 个无任务的对未生成保底 relationship_building 任务
- 小燕(assistant_id: 2964673443302213)与葛先生(member_id: 2799207363643141)RS=10.00 超出漏斗 rs_max=6.0,被四级漏斗跳过,保底又静默失败
修复内容
- 将
_generate_baseline_relationship_tasks从_run_for_site()提升到run()主循环的 Step 3 - 函数签名从
(conn, site_id, stats)改为(site_id, stats),内部使用独立biz_conn = _get_connection()+try/finally: biz_conn.close() - 每个 (assistant, member) 对独立 commit/rollback,单条失败不影响其他
ON CONFLICT子句修正为匹配实际索引idx_coach_tasks_site_assistant_member_type:(site_id, assistant_id, member_id, task_type) WHERE status = 'active'- 更新
_run_for_sitedocstring,移除已删除的 Step 3b 描述
本次对话文件变更
新增文件
docs/audit/prompt_logs/prompt_log_20260325_022806.mddocs/audit/session_logs/2026-03/25/12_a42c1bea_021513/main_01_0365745f.mddocs/audit/session_logs/2026-03/25/12_a42c1bea_021513/sub_01_0365745f.mddocs/audit/session_logs/2026-03/25/12_a42c1bea_021513/sub_02_0365745f.md
验证
- 清空测试库任务后重新生成:149 条(2 high_priority_recall + 1 priority_recall + 146 relationship_building)
- 小燕×葛先生任务已生成:relationship_building, RS=10.00
影响范围
task_generator.py:run()、_run_for_site()、_generate_baseline_relationship_tasks()三个函数- 无数据库 schema 变更、无 API 接口变更、前端无需改动
DDL/迁移检查
- 无新增迁移 SQL
改动注解
apps/backend/app/services/task_generator.py
- 变更类型:修改
- 原始原因:用户发现保底 relationship_building 任务生成在四级漏斗事务异常时被静默吞掉,149 个全量服务对中 114 个未生成保底任务。根因是
_generate_baseline_relationship_tasks与_run_for_site共享同一个conn,四级漏斗 rollback 后连接状态不确定,后续操作静默失败。 - 思路分析:将保底函数从
_run_for_site()内部提升到run()主循环,作为独立的 Step 3 在所有门店的四级漏斗(Step 2)完成后执行。函数内部自行创建和管理独立的biz_conn,彻底隔离事务状态。同时修正ON CONFLICT子句从错误的索引名改为匹配实际的idx_coach_tasks_site_assistant_member_typepartial unique index 的列定义。 - 修改结果:保底任务生成不再受四级漏斗事务状态影响,每个 (assistant, member) 对独立 commit/rollback。RS > 6.0 的客户(如小燕×葛先生 RS=10.00)现在能正确生成 relationship_building 保底任务。
apps/backend/tests/unit/test_trigger_jobs_patch.py
- 变更类型:修改(非高风险,简要注解)
- 测试文件同步更新,适配
_generate_baseline_relationship_tasks签名变更。
回滚
恢复 _generate_baseline_relationship_tasks 的旧签名 (conn, site_id, stats) 并移回 _run_for_site() 内部调用即可。