 qyqy
|
8cff6b35f9
|
fix(tests): tmp_path 落点改到仓库内，消除 33 个与缺陷无关的 setup 失败
问题：本机 `%TEMP%\pytest-of-Windows` 被权限更高的会话建过，当前用户无权写入，
于是所有用 `tmp_path` 的用例在 setup 阶段批量 ERROR（WinError 5）——实测 33 个，
散布在 offsite 附件预览、通知发送、promotion、worker 等处。这类噪声会让
"到底哪里坏了"完全看不出来（同事这批新用例首次把它暴露出来）。
修法：在 tests/conftest.py 覆盖 `tmp_path`，把根目录改到仓库内 `.workdir/pytest-tmp`
（已在 .gitignore）。语义不变——每个用例仍拿到一个**新建的空目录**（残留目录会污染断言）。
只覆盖 `tmp_path` 而不动 `tmp_path_factory`：后者是 pytest 私有构造，参数随版本变化
（实测直接实例化 `TempPathFactory(...)` 会 TypeError），而本仓库用例只用 `tmp_path`。
同时把 pyproject.toml 里那条 `basetemp = ...` 删掉：pytest **只在命令行认 basetemp**，
写在 ini 里会被静默忽略（实测无效），留着会让人误以为已配好。改为注释指向 conftest。
效果：不带任何参数 `pytest -q` 从「3 failed + 33 errors」变为「3 failed，0 error」。
|
2026-09-11 19:13:43 +08:00 |
|
|
qyqy
|
636dcbbe7e
|
chore: 修我文件里的 mypy 类型错误（8 处）
源自评审 §1.4「数字不可比」引发的核查，结论比预想更有价值：
**mypy 报错的主因不是代码质量，而是本机缺 SQLAlchemy 2.0 的类型信息。**
装上 `sqlalchemy2-stubs` 后 181 → 43（该类存根是 2.0 之前的旧包，会换一批新错：
`mapped_column`/`DeclarativeBase` 不存在），卸载后回到 184。**本机 mypy 数字不可作为
质量结论，双方也不可比。** 但那 184 里有 8 个是**我文件里的真实错误**，已修：
- `knowledge_retrieval_service`：返回类型 `Mapping` → `dict`（回表后要就地补写
`score`/`intent`，而 `Mapping` 是只读协议）；`ids` 显式标注并过滤 `None`；
去掉 3 处已失效的 `type: ignore`（strict 下 unused-ignore 本身是错误）
- `knowledge_management`：服务工厂返回类型 `Any` → `KnowledgeManagementService`
（`TYPE_CHECKING` 期导入，运行时仍惰性，不引入循环依赖），消掉 3 个 `no-any-return`
未动的：`model_gateway` 2 处 `dict-item`（`ModelEndpointConfig` 实际具备协议要求的
全部字段，属 SQLAlchemy `Mapped[T]` 在缺存根时的消解问题，不是真缺陷，不用 cast 掩盖）。
|
2026-09-11 19:13:43 +08:00 |
|
 yuancong_0626
|
fd9598efdf
|
袁聪的第二次提交，项目已完整
|
2026-09-11 16:57:47 +08:00 |
|
|
yuancong_0626
|
5907fcd6d2
|
袁聪的第一次提交，包含nl2sql,行情数据,场外申购
|
2026-09-10 09:23:22 +08:00 |
|
|
Codex
|
b1497fd2c6
|
chore: initialize project repository
|
2026-09-09 21:55:37 +08:00 |
|