track

Author SHA1 Message Date

Author	SHA1	Message	Date
duxingchen	39697ca3ad	feat(audit): 每日活动打点表 —— 修正日活「上线/下线时间」口径【问题】上线/下线时间此前取自审计记录（写操作）时间，当天只翻看、没做写操作的人会被整条漏掉；而取登录时间更错（Refresh Token 有效期 7 天，用户不必每天登录，会出现「登录次数 0 却操作 35 次」的自相矛盾报表）。【方案 C+：一天一人一行的小状态表】 - 新增 user_daily_seen(user_id, day, first_seen_at, last_seen_at)，迁移 k1l2m3n4o5p6（紧接 j1k2l3m4n5o6） - 打点挂在 RequestContextMiddleware —— 它是最外层，能覆盖【所有】请求，含不被审计的普通 GET。挂审计中间件没用：那里只记写操作，正是漏人的原因 - 节流：进程内缓存，同一用户 2 分钟内只落盘一次，把"每请求一次写库" 压到"每人每 2 分钟一次"；代价是末次活动时间最多落后 2 分钟 - UPSERT on_conflict_do_update 只刷 last_seen_at，first_seen_at 保持当天首次值 - 打点失败全部吞掉并记日志，绝不影响业务请求【为什么不复用 audit_logs】「末次活动」是需要不断 UPDATE 的状态，而审计流水必须只增不改 —— 能改的审计记录等于没有审计价值。写进审计表还会让表随访问量线性膨胀。【查询合并】 get_daily_usage 改为「活动表 ∪ 审计表」并集：只有活动记录的（只看不操作）和只有审计记录的（本表上线前的历史数据）都会出现。上线/下线时间取两者的【最早 / 最晚】而非"活动表优先"——打点有 2 分钟节流、跨零点或写库失败时可能晚于当天第一次写操作，取 min/max 后结果永不劣于任一来源。零前端改动、零移动端发版：打点在服务端，PC 与移动端同一套口径、同一张表。	2026-09-21 13:05:35 +08:00
openhands	04eb87b091	fix: 访问日志的 user 字段恒为 null —— 改用 request.state 跨 task 传递上一提交(`4454047`)的 RequestContextMiddleware 通过 contextvar 读取 user，但 Starlette 的 BaseHTTPMiddleware 用 anyio start_soon 把下游放进新 task 执行，而 asyncio 每个 Task 创建时会复制 context —— 路由内 set 的 contextvar 不会回流到中间件，导致访问日志的 user 永远是 null。修复： - get_current_user 同时写 contextvar（供请求任务内业务日志用）与 request.state（由 ASGI scope 承载，跨 task 可见），并带上 display_name / role 备用。 - 中间件 _log_access 改为优先读 request.state.audit_user。验证（TestClient + 解析最终 JSON 输出，而非读 record 属性）： - track.access 日志 user=zhangsan01（经 request.state） - 请求任务内 track.service 日志 user=zhangsan01（经 contextvar） - 两者 request_id 一致；X-Request-ID 透传正常	2026-09-21 02:11:41 +00:00
openhands	4454047ce3	fix: 修复任务分页总数错误 + 补齐可观测性基建分页总数（#5）： - get_all_tasks 的 total 原为 len(flat_tasks)（当前页条数），移动端「我的任务」用 tasks.length < total 判断 hasMore，首页满员时恒为 false，列表永远停在第一页 20 条。改为独立 COUNT 查询（与 notifications.py 已有写法保持一致）。可观测性（#9）： - 新增 core/logging.py：单行 JSON 结构化日志 + request_id/user 上下文注入；零第三方依赖；接管 uvicorn 自带 handler 避免格式绕过。 - 新增 core/middleware.py：RequestContextMiddleware 生成/透传 X-Request-ID 并回写响应头，输出含耗时/用户的结构化访问日志。 - 新增 core/health.py：拆分存活/就绪探针。/health/live 不触依赖； /health/ready 探主库，不可用返回 503；MOM 挂掉仅降级不摘流量。 - main.py：全局异常处理器只把堆栈写日志，响应体仅回 request_id；接入可选 Sentry（未装 SDK 时静默跳过）。 - auth_service：解析 Token 后写入 user 上下文，日志自动带操作人。注：异常处理器由 ServerErrorMiddleware 调用，此时 contextvar 已被重置，故 request_id 同时写入 request.state（由 ASGI scope 承载）再读取。已用 TestClient 验证：探针状态码/检查项、X-Request-ID 透传与生成、 500 响应携带可对账的 request_id 且不泄露堆栈。	2026-09-21 01:57:20 +00:00

duxingchen

39697ca3ad

【问题】
上线/下线时间此前取自审计记录（写操作）时间，当天只翻看、没做写操作的人
会被整条漏掉；而取登录时间更错（Refresh Token 有效期 7 天，用户不必每天登录，
会出现「登录次数 0 却操作 35 次」的自相矛盾报表）。

【方案 C+：一天一人一行的小状态表】
- 新增 user_daily_seen(user_id, day, first_seen_at, last_seen_at)，
  迁移 k1l2m3n4o5p6（紧接 j1k2l3m4n5o6）
- 打点挂在 RequestContextMiddleware —— 它是最外层，能覆盖【所有】请求，
  含不被审计的普通 GET。挂审计中间件没用：那里只记写操作，正是漏人的原因
- 节流：进程内缓存，同一用户 2 分钟内只落盘一次，把"每请求一次写库"
  压到"每人每 2 分钟一次"；代价是末次活动时间最多落后 2 分钟
- UPSERT on_conflict_do_update 只刷 last_seen_at，first_seen_at 保持当天首次值
- 打点失败全部吞掉并记日志，绝不影响业务请求

【为什么不复用 audit_logs】
「末次活动」是需要不断 UPDATE 的状态，而审计流水必须只增不改 ——
能改的审计记录等于没有审计价值。写进审计表还会让表随访问量线性膨胀。

【查询合并】
get_daily_usage 改为「活动表 ∪ 审计表」并集：只有活动记录的（只看不操作）
和只有审计记录的（本表上线前的历史数据）都会出现。
上线/下线时间取两者的【最早 / 最晚】而非"活动表优先"——打点有 2 分钟节流、
跨零点或写库失败时可能晚于当天第一次写操作，取 min/max 后结果永不劣于任一来源。

零前端改动、零移动端发版：打点在服务端，PC 与移动端同一套口径、同一张表。

2026-09-21 13:05:35 +08:00

openhands

04eb87b091

fix: 访问日志的 user 字段恒为 null —— 改用 request.state 跨 task 传递

上一提交(4454047)的 RequestContextMiddleware 通过 contextvar 读取 user，
但 Starlette 的 BaseHTTPMiddleware 用 anyio start_soon 把下游放进新 task
执行，而 asyncio 每个 Task 创建时会复制 context —— 路由内 set 的
contextvar 不会回流到中间件，导致访问日志的 user 永远是 null。

修复：
- get_current_user 同时写 contextvar（供请求任务内业务日志用）与
  request.state（由 ASGI scope 承载，跨 task 可见），并带上
  display_name / role 备用。
- 中间件 _log_access 改为优先读 request.state.audit_user。

验证（TestClient + 解析最终 JSON 输出，而非读 record 属性）：
- track.access 日志 user=zhangsan01（经 request.state）
- 请求任务内 track.service 日志 user=zhangsan01（经 contextvar）
- 两者 request_id 一致；X-Request-ID 透传正常

2026-09-21 02:11:41 +00:00

openhands

4454047ce3

fix: 修复任务分页总数错误 + 补齐可观测性基建

分页总数（#5）：
- get_all_tasks 的 total 原为 len(flat_tasks)（当前页条数），移动端
  「我的任务」用 tasks.length < total 判断 hasMore，首页满员时恒为
  false，列表永远停在第一页 20 条。改为独立 COUNT 查询（与
  notifications.py 已有写法保持一致）。

可观测性（#9）：
- 新增 core/logging.py：单行 JSON 结构化日志 + request_id/user 上下文
  注入；零第三方依赖；接管 uvicorn 自带 handler 避免格式绕过。
- 新增 core/middleware.py：RequestContextMiddleware 生成/透传
  X-Request-ID 并回写响应头，输出含耗时/用户的结构化访问日志。
- 新增 core/health.py：拆分存活/就绪探针。/health/live 不触依赖；
  /health/ready 探主库，不可用返回 503；MOM 挂掉仅降级不摘流量。
- main.py：全局异常处理器只把堆栈写日志，响应体仅回 request_id；
  接入可选 Sentry（未装 SDK 时静默跳过）。
- auth_service：解析 Token 后写入 user 上下文，日志自动带操作人。

注：异常处理器由 ServerErrorMiddleware 调用，此时 contextvar 已被重置，
故 request_id 同时写入 request.state（由 ASGI scope 承载）再读取。

已用 TestClient 验证：探针状态码/检查项、X-Request-ID 透传与生成、
500 响应携带可对账的 request_id 且不泄露堆栈。

2026-09-21 01:57:20 +00:00

3 Commits