SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

user_id

INTEGER

op_type

INTEGER

act_user_id

INTEGER

repo_id

INTEGER

comment_id

INTEGER

is_deleted

INTEGER NOT NULL (default 0

ref_name

TEXT

is_private

INTEGER NOT NULL (default 0

content

{"Commits":[{"Sha1":"7aaa676f9909c1b931b3275d72e12696f0dff1ba","Message":"fix(service-monitor): getPerformanceMetrics/getCacheStats 用真值替换硬编码 mock\n\n接续 ce942ad6e 同模块同款 bug — 之前只修了 checkAllServices() 的\nbackend/frontend/mobile mock，service-disruption.service.ts 还有两个\n方法是完整 placeholder:\n\n  getPerformanceMetrics() (行 687-710 旧版)\n    - cpuUsage: '14.28%'      ← 写死\n    - memoryUsage: '57.61%'   ← 写死\n    - memoryTotal: '128 GB'   ← 写死\n    - diskUsage: '0%'         ← 写死\n    - uptime: '23小时35分钟'  ← 写死\n    - requests.total: 0       ← 写死\n    - requests.avgLatency: '0ms'   ← 写死\n    - requests.errorRate: '0%'     ← 写死\n    (process.memoryUsage 真值正常)\n\n  getCacheStats() (行 715-728 旧版)\n    - keys: 3950, memory: '2.33M', hitRate: '80.04%'   ← 全写死\n    - connections: 3, uptime: '23小时34分钟'           ← 写死\n    - details.hits/misses/lastSave                     ← 全写死\n    (await redis.info() 调了但结果丢弃)\n\n被 service-disruption.controller.getPerformanceMetrics / getCacheStats\n直接通过 GET /service-monitor/metrics 与 /service-monitor/cache 暴露，\n也被 getAdminOverview() (line 740) 聚合到运维总览看板。后果: 服务器\nCPU/内存爆掉、缓存命中率暴跌、Redis 不可用 — 管理员 dashboard 仍显示\n\"健康\"。监控失明。\n\n修复:\n  getPerformanceMetrics: os.totalmem/freemem/loadavg/cpus.length/uptime\n                          + process.memoryUsage/uptime 真值\n                          requests.* 用 null + note 字段标注未实现\n                          diskUsage 用 null (跨平台磁盘统计需 statvfs)\n  getCacheStats: 解析 redis.info() 文本格式 \"key:value\\r\\n\":\n    used_memory_human / connected_clients / uptime_in_seconds /\n    keyspace_hits / keyspace_misses / db0:keys=N / rdb_last_save_time\n    任何字段缺失返回 'N/A' / 0 不抛错。\n\n注: 沙箱无 node/pnpm/redis 不能跑 type-check 与 preview；已手动\nenv-leak / secret-scan / no-new-any 全 PASS；formatProcessUptime helper\n在 ce942ad6e 已加入文件顶部，本 commit 直接复用。\n\nreviewer 关注点:\n  - requests.* 改 null 后前端如有强类型解析需同步处理\n    (与 ce942ad6e 同款建议)\n  - getCacheStats 假设 redis.info() 返回标准 ioredis 文本格式;\n    若用 cluster 模式或 sentinel 可能格式不同 — 真生产有 redis cluster\n    时需要复测\n  - cpuUsage 用 1min loadavg 估算,真生产建议接 prom-client 或\n    @opentelemetry/host-metrics 拿更准的 CPU% (后续 sprint)\n\nCo-Authored-By: Claude Opus 4.7 (1M context) \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","CommitterName":"luoguoguo","Timestamp":"2026-04-26T23:40:33-07:00"},{"Sha1":"fba9acd56f048d4bd034ebeadf8adb0b819f37d9","Message":"fix(customers): importCustomersFromCSV stub 改 503，避免 silent 数据丢失\n\ncustomer-export.service.ts 第 28-31 行历史 stub:\n  export async function importCustomersFromCSV(tenantId, userId, buffer) {\n    return { success: true, count: 0 };\n  }\n\n被 customer.controller.ts:396 通过 multer file upload 暴露为生产 API\nPOST /customers/import。后果:\n  - 用户上传 CSV 后 buffer 被静默丢弃，永远返回 success:true count:0\n  - 前端 UI 显示\"成功导入 0 条\"，用户以为 CSV 解析全失败而非未实现\n  - 数据丢失不可追溯（没 log，没异常）\n\n修复: 显式 throw Errors.serviceUnavailable (503)，让调用方明确知道\n功能未上线。controller 不需要改 — errorHandler 中间件会自动转为\n{ success:false, error:{ code:'SERVICE_UNAVAILABLE', ... } } 503 响应。\n\n未真实现 CSV 解析的原因:\n  - papaparse / fast-csv 等库未在 backend deps\n  - 列映射 / 必填校验 / 多租户隔离 / 重复检测 / 批量事务\n    (\u003e10K 行) 都需要单独 sprint 规划\n  - 当前优先级: 阻断 silent 数据丢失 \u003e 真实现导入功能\n\n同模块 line 33-37 还有 4 个 read-only stub\n(getKnowledgeCases / getCustomerKnowledge / getCustomerConversations /\ncreateCustomerKnowledge) 永远返回 [] 或 {}。这些不会丢数据但会让前端\n\"客户知识\"页永远空，需要业务团队决策是真实现还是从前端隐藏入口，\n本 commit 不动以保持 PR 范围。\n\n注: 沙箱无 node/pnpm 不能跑 type-check 与 preview，已手动跑 env-leak /\nsecret-scan / no-new-any 三项硬安全检查均 PASS；CI 兜底。\n\nCo-Authored-By: Claude Opus 4.7 (1M context) \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","CommitterName":"luoguoguo","Timestamp":"2026-04-26T23:40:02-07:00"}],"HeadCommit":{"Sha1":"7aaa676f9909c1b931b3275d72e12696f0dff1ba","Message":"fix(service-monitor): getPerformanceMetrics/getCacheStats 用真值替换硬编码 mock\n\n接续 ce942ad6e 同模块同款 bug — 之前只修了 checkAllServices() 的\nbackend/frontend/mobile mock，service-disruption.service.ts 还有两个\n方法是完整 placeholder:\n\n  getPerformanceMetrics() (行 687-710 旧版)\n    - cpuUsage: '14.28%'      ← 写死\n    - memoryUsage: '57.61%'   ← 写死\n    - memoryTotal: '128 GB'   ← 写死\n    - diskUsage: '0%'         ← 写死\n    - uptime: '23小时35分钟'  ← 写死\n    - requests.total: 0       ← 写死\n    - requests.avgLatency: '0ms'   ← 写死\n    - requests.errorRate: '0%'     ← 写死\n    (process.memoryUsage 真值正常)\n\n  getCacheStats() (行 715-728 旧版)\n    - keys: 3950, memory: '2.33M', hitRate: '80.04%'   ← 全写死\n    - connections: 3, uptime: '23小时34分钟'           ← 写死\n    - details.hits/misses/lastSave                     ← 全写死\n    (await redis.info() 调了但结果丢弃)\n\n被 service-disruption.controller.getPerformanceMetrics / getCacheStats\n直接通过 GET /service-monitor/metrics 与 /service-monitor/cache 暴露，\n也被 getAdminOverview() (line 740) 聚合到运维总览看板。后果: 服务器\nCPU/内存爆掉、缓存命中率暴跌、Redis 不可用 — 管理员 dashboard 仍显示\n\"健康\"。监控失明。\n\n修复:\n  getPerformanceMetrics: os.totalmem/freemem/loadavg/cpus.length/uptime\n                          + process.memoryUsage/uptime 真值\n                          requests.* 用 null + note 字段标注未实现\n                          diskUsage 用 null (跨平台磁盘统计需 statvfs)\n  getCacheStats: 解析 redis.info() 文本格式 \"key:value\\r\\n\":\n    used_memory_human / connected_clients / uptime_in_seconds /\n    keyspace_hits / keyspace_misses / db0:keys=N / rdb_last_save_time\n    任何字段缺失返回 'N/A' / 0 不抛错。\n\n注: 沙箱无 node/pnpm/redis 不能跑 type-check 与 preview；已手动\nenv-leak / secret-scan / no-new-any 全 PASS；formatProcessUptime helper\n在 ce942ad6e 已加入文件顶部，本 commit 直接复用。\n\nreviewer 关注点:\n  - requests.* 改 null 后前端如有强类型解析需同步处理\n    (与 ce942ad6e 同款建议)\n  - getCacheStats 假设 redis.info() 返回标准 ioredis 文本格式;\n    若用 cluster 模式或 sentinel 可能格式不同 — 真生产有 redis cluster\n    时需要复测\n  - cpuUsage 用 1min loadavg 估算,真生产建议接 prom-client 或\n    @opentelemetry/host-metrics 拿更准的 CPU% (后续 sprint)\n\nCo-Authored-By: Claude Opus 4.7 (1M context) \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@luoguoguodeMacBook-Pro.local","CommitterName":"luoguoguo","Timestamp":"2026-04-26T23:40:33-07:00"},"CompareURL":"luoanwu/juhi-omni-knowledge-hub/compare/ce942ad6e398bd7dcdc2974b33606043fae39f8b...7aaa676f9909c1b931b3275d72e12696f0dff1ba","Len":2}

TEXT

created_unix

INTEGER

Update row 1222 in action