 zhangshy
|
eb4e895e4e
|
修复高风险预警邮件通知并补充测试
|
2026-09-12 15:56:50 +08:00 |
|
 lzf_0626
|
8d79bd9767
|
补齐三个成功响应缺失的 meta 信封；信封实现抽为公共（docs/05 §3.3）
"缺 meta"很容易被误判成"有"：X-Trace-ID 是**响应头**（中间件加），和 body 里的
meta.trace_id 是两件事；错误响应一直有 meta（异常处理器统一加），漏的只有成功路径。
核到三个端点在把 service 的内部结构直接当响应体返回：
- GET /conversations/{session_id}/messages → 裸 {"data": [...]}，meta 整个缺失，
游标也没地方放（§3.3 要求列表的 data 为纯数组、next_cursor/has_more 进 meta）
- POST /conversation-messages/{id}/feedback → 同样没有 meta
- GET /knowledge-references/{token} → 直接返回资源对象
改动：
- 新增 app/api/views/envelope.py，把 envelope / list_envelope 抽成一份公共实现，
风控链路改为复用它 —— 同一份契约写两遍的结果就是其中一处漏了 meta。
- ConversationService.messages 改为返回内部结构 {items, next_cursor, has_more}，
用 limit + 1 判断 has_more：只看"取满没取满"会把恰好等于 limit 的最后一页说成
还有下一页。next_cursor 取本页最后一条的 message_id —— 游标语义是"取更旧的一页"，
天然可续，集成测试本来就是这么翻页的。
- Controller 统一套信封，data 仍是数组、字段名不变，前端不需要改。
测试：新增 tests/unit/api/test_response_envelope.py，断言 set(body) == {"data","meta"}
（多或少一个顶层字段都会红），并覆盖 has_more / next_cursor / trace_id；
另更新两处既有断言（limit 20→21、feedback 返回裸对象）。
门禁：ruff 干净 / mypy 138 文件 / 696 unit+contract / 33 integration。
|
2026-09-11 15:21:36 +08:00 |
|
|
lzf_0626
|
15866d4564
|
风控写接口接入平台幂等（docs/25 P3 #22）
docs/05 §5.1 把"业务写接口"列为必须携带 Idempotency-Key 的接口，风控 6 个 POST
（手工扫描、确认接收、进入调查、关闭误报、完成结案、升级处理）此前一个都没带，
重复提交会二次驱动状态机。
复用平台的 api_request_receipt 与 ApiTransactionService，但新增 execute_in：原来的
execute 自己开 SessionFactory() 和 session.begin()，而 RiskActionService._finish
会在内部 commit，套进去就成了"内层提交外层事务"。execute_in 改为在调用方传入的
session 上读写幂等记录，幂等记录因此与业务写入同处一个事务（§5.2）。
scope 用实际路径（含 alert_no）而不是路由模板：§5.1 的幂等范围是
user_id + method + normalized_path + idempotency_key，把路径参数折成模板会让同一个键
在不同预警之间互相回放 —— 那是把两次不同资源的操作当成一次。
测试：单测加幂等透传替身与"缺键即 422"用例；新增
tests/integration/test_risk_idempotency_mysql.py，覆盖同键回放不重复执行、同键不同
正文 409、缺键/非 ASCII 拒绝，以及端到端"重复 POST 只调用一次处置逻辑"。
|
2026-09-11 14:12:56 +08:00 |
|
|
lzf_0626
|
790518114b
|
风控 SSE 内容协商与鉴权时序；docs/05 补齐 413 与风控入口（docs/25 P3 #23 #24 #25）
#23：413 是上传超限的标准语义，前端文档（风控业务演示文档 17）也已按 413 做提示
映射，所以不把代码降成 422，而是在 docs/05 §3.5 状态码表补登 413 —— 契约以"补齐"
而不是"改动"的方式对齐。
#24：/api/v1/risk/daily-report/stream 此前既不校验 Accept，又把鉴权留在 async
generator 内部。后者更隐蔽：StreamingResponse 已经返回、响应头已经发出，403 只能
变成"200 + 半截流"。现在 controller 先 await service.authorize(context) 再判定
Accept，顺序与 §6.4 一致（鉴权先行，不用状态码差异做探测）。SSE 协商逻辑抽到
app/api/dependencies/negotiation.py，与 /agent-runs/{run_id}/events 共用同一口径，
避免同一种客户端在一个端点上 200、另一个端点上 406。
#25：复核后确认前半段不成立 —— §19 末尾写明业务域接口由各自业务文档登记，风控 15 条
端点已在 06-模块接口与字段映射.md 逐条登记。真问题是 §12 表里写的
/api/v1/risk-scans/**、/api/v1/risk-alerts/** 与实际实现 /api/v1/risk/** 不符，
按实际实现更新 §12 并加说明；顺带把风控文档里 /daily-report/mail 的权限从
"按主项目邮件策略执行"改为实际的 risk:report:mail。
新增 tests/unit/api/test_risk_stream_negotiation.py（7 例）。
|
2026-09-11 14:08:55 +08:00 |
|
|
lzf_0626
|
e8b075bc7f
|
fix(risk): 列表接口的信封对齐 docs/05 §3.3——游标从 data 挪到 meta
docs/05 §3.3 的列表样例是 data 为**纯数组**、
ext_cursor 与 has_more 放在 meta 里，
并明确「业务接口不得增加其他顶层字段」。而 RiskQueryService._page 返回的
{items, next_cursor, has_more} 被**整体塞进 data** —— 游标因此出现在**业务数据**里，
meta 只剩 trace_id，两处都不符合契约。
改动：
- 新增 _list_envelope(page, context)：把 _page 的结构拆成 data = items、
meta = {trace_id, next_cursor, has_more}。**service 侧不动** —— 它继续返回那个内部
结构，只是不再直接当 data 用。
- 3 个列表端点改用它：/alerts、/evidence/{source}、/notifications。
非列表端点（overview、详情、各类写操作）保持原样，不带游标。
**影响调用方**：这是接口形状变更。组员若写了前端读 data.items，需要改成读 data、
并从 meta 取分页元数据。改动依据是 docs/05 这个唯一权威接口文档（§20 也要求实现与
文档同步）。**合并时要提醒组员。**
**实测**（9002 身份）：
- /alerts?limit=2 → 顶层键 ['data','meta']、data 是 list（2 条真实数据）、
meta 键 ['has_more','next_cursor','trace_id']
- /evidence/customers 与 /notifications 同形状
- 对照 /overview（非列表）→ meta 只有 trace_id、不带游标
**测试**：3 处断言从 data["items"] 改为 data；/notifications 那处补上对 meta 的断言；
新增 test_list_endpoints_follow_the_documented_envelope，直接断言"data 是纯数组、
meta 恰好三个键、顶层恰好 data/meta"，把 §3.3 的契约钉住。
过程里踩了两个自己的坑：① 忘了 rom typing import Any（与 customer_service.py 同一失误，
被 ruff/mypy 当场抓住）；② 漏了 /evidence/{source} 这个列表端点，是测试先失败才发现的。
ruff / mypy(136 文件) / 640 unit+contract / 29 integration 全绿。
|
2026-09-11 14:01:16 +08:00 |
|
|
lzf_0626
|
d896a906cd
|
fix(risk): 规则扫描加跨进程锁——手工触发与定时扫描此前可以同时跑
docs/25 P2 最后一项。核实后分清了两层，报告没区分：
- **定时扫描是安全的**：risk_scan_scheduler.py 已有 MySQL 连接级咨询锁
（GET_LOCK，锁名 jr_risk_scan_schedule），跨进程互斥。
- **HTTP 端点不安全**：POST /api/v1/risk/alerts/scan → RiskScanService.scan() 只用了
**进程内** asyncio.Lock。多 Web worker、或 Worker 与 API 同时运行时形同虚设。
而扫描的幂等只有应用层的 _exists 查重 —— fin_risk_alert 的 trigger_rule_codes 是 JSON
数组，**无法建唯一索引兜底**（同一交易可命中多条规则，唯一键本应是"交易+规则"，而规则
埋在 JSON 里）。所以两条路径并发时会同时查不到、同时插入，产生重复预警。
**改动**：
1. 把 mysql_scan_lock 与锁名移到 pp/infrastructure/db.py —— 端点与调度器**必须共用
同一把锁**，放在基础设施层两个入口才都能引用（service 不该反向依赖 worker）。
调度器改为从那里 import。
2. **端点层加锁**（controllers/risk.py 的 scan 端点）：取不到锁就抛 RiskScanBusyError
（与 service 内部那把进程内锁用同一错误类型与文案）。
**为什么不加在 RiskScanService.scan() 内部**：GET_LOCK 是**连接级**的，而调度器已经在
它自己的 session 上持锁；被两个入口共用的服务方法若再取同一把锁，取锁的连接并不是持锁的
那一个、必然返回 0 —— 会**把定时扫描自己挡死**。所以锁加在入口层，每个入口只取一次。
**实测**：
- 无人持锁时扫描 → **200**「规则扫描完成」
- 本进程先取得跨进程锁后再调端点 → **409**「规则扫描正在执行，请稍后重试」
（同一进程内不同 session 也互斥，说明它是连接级的，正是跨进程所需）
- 释放后再调 → **200**，恢复正常
顺带第 4 次遇到 409 复用错误码 RUN_NOT_CANCELLABLE，语义不符；属 P3 待处理项。
ruff / mypy(136 文件) / 639 unit+contract 全绿。
|
2026-09-11 13:57:22 +08:00 |
|
|
lzf_0626
|
0d3447bde4
|
fix(risk): 日报邮件端点补上授权校验——它此前是风控里唯一没有校验的端点
**问题**：POST /api/v1/risk/daily-report/mail 原先只取 context 做 401 判定，
**没有任何授权校验**；RiskDailyReportMailService.send 既拿不到 context、也不调用
AuthorizationService。收件人、标题、正文**全部由客户端决定** —— 一旦运维开启 SMTP
（RISK_DAILY_REPORT_MAIL_ENABLED），它就是一个未授权的邮件发送器。
默认关闭（ENABLED 默认 false + DRY_RUN 默认 true）让它至今没出事，但那不是可依赖的保护。
**改动**：
- send 改为 async 并接收 context，入口处 wait AuthorizationService.require(
context, "risk:report:mail")。校验放在 **service 层**而不是 controller —— 本项目风控
端点的授权一律落在 service（risk_query / risk_action / risk_scan 等都是这样），
controller 只负责取 context；这个端点是唯一的例外，现在补齐。
- controller 相应改为 wait ...send(..., context=context)。
- 权限
isk:report:mail 已在上一轮随另外三个一起创建并授予 risk_operator 与 admin。
**实测**：
- 9002(risk_operator) → **200** + {"status":"disabled","recipient_count":1}（默认关闭）
- 9001(customer) → **403** AGENT_PERMISSION_DENIED「缺少操作权限」
**测试**：3 个既有用例改为 async 并传入带权限的 context；**新增**
est_mail_service_requires_the_permission，断言无权限身份必须被拒 —— 钉住本次修复。
ruff / mypy(136 文件) / 623 unit+contract / 29 integration 全绿。
|
2026-09-11 13:39:50 +08:00 |
|
|
zhangshy
|
a94d5c754d
|
feat: 迁移奶龙风控业务模块与演示文档
|
2026-09-10 21:03:44 +08:00 |
|