Files
group_fqcd_jr/tests/integration/test_db_timezone_utc.py
T
lzf_0626 6516ccb385 feat: 第二版——接口契约对齐 docs/05,修复静默故障与数据库基线
相对第一版 46fc976 的完整变更。组员迁移对照表见 docs/20。

一、对外契约对齐 docs/05(破坏性,共 4 处,组员需按 docs/20 调整)
1) 配置发布端点改为文档规定的复数资源名:submit→validations、
   approve→reviews(需 body decision)、activate→activations、
   rollback→rollbacks;第一版这 4 个动词式路径 docs/05 从未定义过。
2) 错误码由 8 个笼统码改为 15 个具体语义码(FORBIDDEN→AGENT_PERMISSION_DENIED、
   UNAUTHORIZED→AUTHENTICATION_REQUIRED、CONFLICT→RESOURCE_VERSION_CONFLICT、
   RESOURCE_NOT_FOUND→RUN_NOT_FOUND/SESSION_NOT_FOUND 等),
   输入类错误状态码 400→422。
3) POST /api/v1/agent-runs 与 GET /api/v1/agent-runs/{run_id} 统一为
   {data, meta} 信封(data 内字段名与语义未变)。
4) 错误响应体统一为 {error:{code,message,retryable,field_errors}, meta:{trace_id}},
   不再返回 FastAPI 默认的 {"detail": ...}。

二、数据库基线与约束
新增 39 张表的基线迁移(链根)与联合唯一键纠偏(4 张表、删 8 增 4,幂等收敛);
撤下 config_release 的双人复核 CHECK(应用层已允许自审,审核节点保留,
自审如实写入 reviewer_id);记忆 active key 生成列与唯一键;
activate 开始记录 supersedes_release_id 使版本链可追溯。
docs/00 基线未修改,未重命名或删除任何表与字段。

三、修复会静默出错或无报错的缺陷
- 跑完集成测试后平台会静默失去生效配置:清理只删自己创建的版本,却没有恢复被它
  顶成 superseded 的原生效版本,且审计一并删除因而完全无痕,表现为所有工具被拒
  但没有任何报错。已修清理逻辑并加恢复。
- Worker 单轮异常导致进程退出;记忆抽取调用方的“事务已开始”异常;
  召回缓存丢失 degraded 标记;连接时区未生效导致 created_at/updated_at 差 8 小时;
  .env 与 os.getenv 密钥来源分裂导致“没有可用的已批准模型端点”。
- 记忆信号识别漏判与跨键误命中;SSE 未带 Accept 的协商行为。

四、功能补齐
记忆链路 P1/P2/P3(抽取、受控词表、召回与缓存、生命周期级联及投影事件)、
fin_* 场内交易只读 ORM 层、agent_intent_config 状态流转并在运行期真正生效、
限流(Redis 固定窗口、故障一律放行)、游标校验、trace_id 中间件、
示例业务 Agent fund_query_demo 与一键端到端验证脚本,以及审计/指纹/迁移状态工具。

五、文档与验证
新增 docs/19(业务 Agent 接入实操)、docs/20(第一版迁移指南)与 docs/evidence 证据;
docs/01/02/06/08/09/17 同步实现现状。

验证结果:ruff 通过、mypy 103 文件无错、unit+contract 447 passed、
integration 29 passed、acceptance_check --production 7 PASS、
demo_agent_e2e 9/9 PASS(含失败关闭反证)。
2026-09-10 15:55:54 +08:00

75 lines
3.0 KiB
Python

"""会话时区回归测试:存储层必须统一 UTC。
为什么值得单独一条集成测试:这个缺陷的表现是"数据照写、接口照跑、时间悄悄错 8 小时",
只有在比较 DB 默认值与默认值之外的第二个时间源时才会暴露。历史上它造成过一次真实
故障——给 `sys_user_role.assigned_at` 用 MySQL `NOW()` 写入的时间超前 UTC 8 小时,
被 RBAC 的 `assigned_at <= now` 判为"尚未生效",接口直接 403。
同时锁住实现方式:`init_command` 必须仍在 DSN 上。曾试过用 SQLAlchemy 的 `connect`
事件写 `SET time_zone`,在 asyncmy 这套 asyncio 方言上**不报错也不生效**,
静默退回本地时区——所以这里断言的是"连接后的会话时区"这一可观测事实。
"""
import pytest
from sqlalchemy import text
from app.infrastructure.db import SessionFactory
UTC_OFFSET_SECONDS = 0
@pytest.mark.integration
async def test_mysql_session_timezone_is_utc():
async with SessionFactory() as session:
time_zone = (await session.execute(text("SELECT @@session.time_zone"))).scalar()
offset = (
await session.execute(
text("SELECT TIMESTAMPDIFF(SECOND, UTC_TIMESTAMP(6), NOW(6))")
)
).scalar()
assert time_zone == "+00:00", f"会话时区应被钉在 UTC,实际 {time_zone!r}"
assert offset == UTC_OFFSET_SECONDS, f"会话时间与 UTC 相差 {offset} 秒,应为 0"
@pytest.mark.integration
async def test_db_default_timestamp_matches_application_utc():
"""DB 的 `CURRENT_TIMESTAMP` 默认值必须与应用侧 `datetime.now(UTC)` 同源。
断言方式刻意不依赖具体时区:同一行里写入一次 DB 默认值和一次应用值,
两者相差必须为 0 秒——改动前这条断言会得到 28800 秒。
"""
from datetime import UTC, datetime
async with SessionFactory() as session:
await session.execute(
text(
"CREATE TEMPORARY TABLE tz_default_probe ("
" id INT PRIMARY KEY,"
" db_default DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),"
" app_value DATETIME(6) NOT NULL)"
)
)
app_now = datetime.now(UTC).replace(tzinfo=None)
await session.execute(
text(
"INSERT INTO tz_default_probe (id, app_value) VALUES (:id, :app_value)"
),
{"id": 1, "app_value": app_now},
)
row = (
await session.execute(
text(
"SELECT db_default, app_value,"
" TIMESTAMPDIFF(SECOND, app_value, db_default) AS gap_seconds"
" FROM tz_default_probe WHERE id = 1"
)
)
).mappings().one()
await session.execute(text("DROP TEMPORARY TABLE tz_default_probe"))
assert row["gap_seconds"] == UTC_OFFSET_SECONDS, (
f"DB 默认值 {row['db_default']} 与应用写入 {row['app_value']} 相差 "
f"{row['gap_seconds']} 秒,说明会话时区未统一到 UTC"
)