"缺 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。
22 lines
1006 B
Python
22 lines
1006 B
Python
from fastapi import APIRouter, Depends, Path
|
|
|
|
from app.api.dependencies.auth import build_request_context
|
|
from app.api.dependencies.rate_limit import enforce_rate_limit
|
|
from app.api.views.envelope import envelope
|
|
from app.core.contracts import RequestContext
|
|
from app.service.knowledge_service import KnowledgeReferenceService
|
|
|
|
router = APIRouter(prefix="/api/v1/knowledge-references", tags=["knowledge"],
|
|
dependencies=[Depends(enforce_rate_limit)])
|
|
|
|
|
|
@router.get("/{reference_token}")
|
|
async def resolve_reference(
|
|
reference_token: str = Path(min_length=20, max_length=300),
|
|
context: RequestContext = Depends(build_request_context), # noqa: B008
|
|
) -> dict[str, object]:
|
|
# §3.3:成功响应也要有 `meta.trace_id`。此前这里直接返回资源对象,客户端拿不到
|
|
# 本次请求的追踪标识,出问题时无法与服务端日志对上。
|
|
data = await KnowledgeReferenceService().resolve(context, reference_token)
|
|
return envelope(data, context)
|