257 Commits

Include renames

Author	SHA1	Message	Date
yml2213	98a9f0e0bc	chore(merge): 账号事件迁移改号 0041，并去重排查报告 ... dev 与 main 从 294c6cd 分叉后，各自新增了一个 0040 迁移（都从 20261002_0039 起链）： - main：20261003_0040 douyu_tasks.account_assigned_to（生产已应用） - dev： 20261002_0040 account_events（未上生产） 两者合并即两个 alembic head，upgrade head 会直接失败。因为账号事件迁移从未被生产库 应用过，改号是安全的： 1. account_events 迁移改名为 20261003_0041，down_revision 指向 20261003_0040； 2. tests/test_migrations.py 的 HEAD_REVISION 同步改 20261003_0041； 3. 迁移保持幂等，本机开发库（alembic_version 已是 20261003_0040、account_events 表已存在） 实跑 upgrade 通过，仅推进版本号、数据未动； 4. 顺带修正规划/解耦设计里「下一个迁移编号」的过期取值（现为 20261003_0042）。 排查报告去重：两个会话各自写了一份《生产服务器高负载排查…》报告，内容重叠且互相矛盾 （一处写 8 核/16GB，另一处有 nproc 原始输出为 4 vCPU/7.1GiB）。合并为单一文档 docs/生产服务器高负载排查与优化报告.md，以带原始命令输出的事实为准，删除重复的那份， 并修正引用它的迁移方案文档。	2026-10-04 13:20:36 +08:00
yml2213	e88c41385b	Merge branch 'main' into dev ... # Conflicts: # tests/test_migrations.py	2026-10-04 13:17:43 +08:00
yml2213	7790be4e04	perf(douyu-tasks): 为斗鱼任务增加归属客服索引字段，彻底消除全表 filesort 慢查询 ... 1. 数据库新增迁移 20261003_0040，在 douyu_tasks 表增加 account_assigned_to 字段，并创建 (account_assigned_to, handbook_scope, id) 与 (account_assigned_to, id) 复合覆盖索引； 2. 迁移脚本自动回填历史 24 万条任务的所属客服 ID； 3. 任务服务与账号路由联动：创建任务时自动继承 account_assigned_to，修改账号分配时同步更新关联任务归属； 4. 斗鱼任务查询路由 _visible_tasks_query 改为通过 account_assigned_to 复合索引过滤，消除与 accounts 表的跨表关联与临时表全量文件排序； 5. 新增 test_douyu_task_assigned_optimization 单元测试并通过整链迁移与回归测试。	2026-10-03 13:10:59 +08:00
yml2213	834bfdd1d0	feat(account-events): 账号详情页与账号事件历史全链路支持 ... 1. 新增账号事件数据表 AccountEvent 与迁移版本 20261002_0040_account_events，支持审计 Cookie 变更、自动重登、健康检查及任务执行事件； 2. 后端新增 account_events_service 并扩展 /api/accounts 路由，支持事件查询、过滤与上报； 3. 前端新增 AccountDetailPage 账号详情页组件，支持账号元信息展示、事件历史瀑布流与快捷重登操作； 4. 修复 CK 重登与自动化定时任务中事件关联逻辑，补充 test_account_events 单元测试； 5. 新增生产服务器高负载排查分析报告及相关设计文档。	2026-10-03 12:58:58 +08:00
yml2213	8310a9115e	fix(login): 删除任务不再丢 CK —— 只删不持有 CK 的记录【数据安全】 ... 事故：斗鱼账号的 CK **只存在 `login_tasks.cookie`**（`accounts` 表没有 cookie 列），删掉记录即永久丢失登录态。而列表显示的「状态」是最近一次尝试 （`attempt_status`），于是一条**显示「失败」但实际仍持有有效 CK** 的记录 （status=success + cookie + 上次尝试失败）会被「清空失败」当成垃圾删掉。 修复： - 批量删除只删空 cookie 的记录，持有 CK 的一律跳过，并在响应里报告跳过数； - 单条删除遇到持有 CK 的记录直接 409，提示先处理该账号的 CK； - 前端确认弹窗写明「持有 CK 的记录会跳过」。 顺带修统计口径：分页后 success/failed 只统计当前页，却和「共 N 个任务」 并排显示（曾出现「共 8508，成功 48」）。改走 /tasks/summary 的全局统计。 回归测试补 5 条，专门盯「显示失败但持有 CK」这个事故场景。	2026-10-03 10:50:23 +08:00
yml2213	1722b0a81b	fix(login): 翻页请求不再被轮询吞掉 ... loadTasks 原来用「有请求在跑就直接返回」防重入，加了分页后这会把用户点 翻页/改筛选时发出的请求一并丢掉：页面停在上一页，要等下一次轮询（3~15s） 才会更新。改为请求序号「最新请求获胜」：过期响应直接丢弃，不再丢请求。	2026-10-03 10:44:52 +08:00
yml2213	7293d758f1	fix(login): 勾选跨页保留，并去掉 loadTasks 的多余依赖 ... 两个自己引入的问题： - loadTasks 依赖 selectedAllMatching 会让每次翻页重建回调，进而触发 上面的 effect 重新加载标签（多余请求）； - 翻页静默清空勾选会让人困惑（「选了 10 个翻页就没了」），改为 preserveSelectedRowKeys 跨页保留，删除数量在按钮上明确显示。	2026-10-03 10:39:53 +08:00
yml2213	a0db26def3	feat(login): 任务列表支持分页、跨页全选与一键清空 ... 任务量早就过了单页能装下的规模（库里 1.4 万条，单批就 177 条），但接口 硬编码 limit(200)、前端 pagination={false}，于是「全选」其实只能选到前 200 条，失败任务清不干净。 - 接口加 page/page_size/status：不传 page 时仍返回裸数组（Cookie 页等 老调用方依赖这个契约，不能改）；传了才返回 {items,total}，total 供跨页全选。 - 删除支持 all_matching：按当前筛选条件删全部，不必先翻完所有页去勾。 - 前端：分页控件（20/50/100/200/500，记住选择）、状态筛选、表头 「选择全部 N 条（含其他页）」、「清空失败」一键操作。 两条护栏： - **pending/running 一律不删** —— 删掉会让批次线程找不到记录；要停批次 走 /stop/{batch_id}。 - 不给任何条件就拒绝删除，绝不默认全删。 顺带：带 join 的 query 不能 bulk delete（SQLAlchemy 会拒绝），改成先查 id 再按主键删。	2026-10-03 10:37:52 +08:00
yml2213	afa5c815f6	feat(orders): P0 订单读取适配层——连 order_site 只读库查订单（默认关闭） ... 让运营能按订单号查到订单，作为后续资料收集（P2）与皮肤准入（P3/P4）的输入。 order_site 零改动：只读直连、独立极小连接池、可一键降级。 上机核实推翻了规划两处假设（详见 §6.5.1）： - orders 表没有 order_no 列，只有 id 与 platform_order_id → 查询入口用后者； - platform_order_id 非唯一：541 组重复，形态固定为「91kaquan 内部行(已发货) + 真实店铺行(无人管)」。按规划原文的单行判据，这 540 个已发货订单会被误判 成「没人管」而放行重复履约。改为**订单号维度聚合**：任一行已发货即 auto_fulfilled。 真机验证（只读账号 livehub_ro）：三桶判定全对，重复组正确拦下并回显真实 店铺行的中文名（狂沙舞者，而非内部码 suit_sand_dancer），单次查询 3.3ms。 顺带修一个只在真机才暴露的 bug：_get_engine 先置 _INITIALIZED 再读 URL， 一次落空就把模块永久毒化成不可用，之后补上连接串也救不回来。	2026-10-02 22:50:20 +08:00
yml2213	d6c6113112	fix(automation): 被重启打断的轮次记为 interrupted，不再混进 failed ... 部署重建容器会打断正在跑的作业，那轮永远写不回结果，由启动时的 cleanup_orphan_runs 收尾。之前收尾成 failed，于是页面上一片红 —— 但这并不是 作业本身的失败：账号侧的 CK 一个没丢（旧 Cookie 已保留），被中断的账号也会按 退避自动重试。混在 failed 里会掩盖真正的失败（如 SQL 语法错误）。 改为独立状态 interrupted，前端用中性灰显示「被中断」，与红色的「失败」区分开。	2026-10-02 22:08:18 +08:00
yml2213	df62898d22	fix(automation): 调度心跳与作业周期解耦，修掉系统性跳轮 ... 线上现象：同一页面上「CK 自动巡检」的最近运行是 21:45:34，而「下次运行」显示 21:50:34 且已经过去了 —— 巡检明明只要 19 秒，却总是等在那里。 根因是把心跳周期直接当成了作业周期：TICK_SECONDS=300 既是「循环多久醒一次」， 又被写进 next_run_at = 作业结束 + 300s。两者同频会系统性跳轮： 心跳 t=0 ck_health 19 秒跑完 → next = 5:19 心跳 t=5:00 差 19 秒没到点 → 整轮空转，什么都不做 心跳 t=10:00 才真正跑到 于是作业实际是每 10 分钟一轮，而不是设计的 5 分钟；只要作业耗时不是刚好 0， 就会稳定地"差一点点"被跳过。两个作业共享同一个心跳时，还会互相把对方的到期 时刻推后。 改动： - 拆成两个常量：TICK_SECONDS=30（心跳，只做「有没有到点的作业」检查，几乎不 耗资源）、JOB_INTERVAL_SECONDS=300（作业周期，跑完一轮后隔多久再跑）。 - next_run_at 改用 JOB_INTERVAL_SECONDS。 - /api/automation/jobs 的 scheduler 同时暴露两个值；启动日志一并打印。 - 页面：「单账号重检间隔」加 tooltip 说明它不决定调度频率（它只控制同一行多久 重检/重试），避免和调度周期混淆。 回归测试（3 条）：心跳必须比作业周期密至少 4 倍；周期未到时连跳多次心跳都不跑； 把 next_run_at 拨到过去后下一次心跳必须跑到。 全量 304 通过。	2026-10-02 21:57:41 +08:00
yml2213	847ed4539a	fix(ui): 运行历史的假耗时、以及「下次运行」显示成过去时间 ... 两处显示问题（来自线上页面核对）： 1. 耗时列：被重启打断的轮次，finished_at 是 cleanup_orphan_runs 在重启后补上的， 于是「耗时」把停机时间也算进去了（线上出现过 235s / 687s 这种假数字）。 改为只有真正扫描过数据的轮次才计算耗时，其余显示 '-' —— 一轮就报错的 （比如历史上的 SQL 语法错误）同理。 2. 下次运行：两个作业串行跑在同一个调度线程里，前一个耗时长时后一个会排队， next_run_at 因此会停在「已经过了」的时刻；直接显示一个过去时间看起来像故障。 改为：未启用 → 「未启用」；已过期 → 「排队中（<时间> 到期，等待前序作业让出 线程）」，未到期照常显示。	2026-10-02 21:51:37 +08:00
yml2213	34d667cba0	fix(automation): 启动时收尾卡在 running 的运行记录 ... 作业是在调度线程里同步跑的：进程一重启（部署、崩溃、手工重启），那一轮就再没 机会写回结果，automation_runs 会永远停在 running，页面上一直显示「执行中」。 登录任务早有孤儿清理，运行记录原先漏了。 线上就是这么暴露的：部署时重建容器打断了正在跑的 ck_relogin 第 14 轮，重启清理 把 20 个在途账号标成了「重新登录中断（旧 Cookie 已保留）」（这部分是对的）， 但 run 14 本身永远卡在 running，detail 为空。 新增 cleanup_orphan_runs()，在启动清理链里调用：把所有 running 的运行记录收尾为 failed + finished_at + 「服务重启中断」。如实记为 failed 而不是 success —— 那轮 确实没跑完；被中断的账号由各自的孤儿清理负责标记并按退避重试。 新增回归测试：只有 running 的被收尾，已完成的不受影响。 （另一件事一并说明：上一次部署我报告「零中断」是验证过早 —— 检查时部署的 up -d 还没执行到。实际情况是 mysql 未被重建（达到了本次改动目的），但应用容器因镜像 变化被正常重建，因此打断了那轮重登。）	2026-10-02 21:35:42 +08:00
yml2213	b34c1ff5f3	fix(automation): 重登结算改用新事务读取，修掉「成功被记成失败」 ... 线上第一轮自动重登（10 条）报告「成功 0 / 失败 10」，但库里这 10 条的 attempt_status 全是 success —— 账号其实都救回来了，是结算读错了。 根因是 MySQL 的隔离级别：默认 **REPEATABLE READ**。调度器传进来的会话在挑候选 时就已经开了事务，而结算复用了这个会话去读 runner（另一个会话）刚提交的结果； 同一事务里重新查询只会看到事务开始时的快照，于是全部读成「未成功」。SQLite 的 读一致性与 MySQL 不同，所以这类问题在 SQLite 上跑一万遍也复现不出来。 后果不只是统计错：失败的账号会被写退避时间，其中 2 条还被判成「极验」进了待 人工队列 —— 等于把救回来的账号又标成需要人工。 改动： - 新增 settle_fresh_results()：自己新开一个会话读结果并结算，绝不复用调度器的 事务；run_ck_relogin 改用它。 （另一路 SQLite→MySQL 的测试改造已把测试套件真正跑在 MySQL 上，本次新增的回归 测试 test_settlement_sees_other_session_commit 正是靠这一点才守得住：它先让一个 会话开着事务，再由另一个会话提交成功，断言结算必须读到成功。）	2026-10-02 21:09:48 +08:00
yml2213	2c532df14f	fix(automation): 待重登积压数不再被批次上限截断 ... 页面上「待重登候选」显示 10 —— 那只是 ck_relogin 的 batch_size，不是真实积压。 根因是我用作业的候选查询取 count，而那个查询带 LIMIT batch_size，count 自然 被截断在批次上限；线上实际有一千多条待重登，页面却恒显示 10。 改为独立的 count_pending_relogin()：同一套资格条件（invalid + 有 CK + 允许自动 管理 + 未转人工 + 未超每日上限），但不带 LIMIT，也不按退避窗口过滤 —— 退避是 「什么时候试」的细节，不影响「还有多少要处理」。 新增测试：批次上限为 10 时，25 条积压必须报 25。 另：本次一并还原了 ck_health.py 里被外部改动引入的回归 —— 有人把选行排序改成 text("login_tasks.ck_checked_at ASC NULLS FIRST")，那是逐字透传给数据库的片段， 而 MySQL 不支持 NULLS FIRST（今天线上就是这么炸的 1064）。已恢复成可移植写法， test_generated_sql_is_mysql_compatible 会拦住这类改动（本次正是它先报的红）。 全量 298 通过。	2026-10-02 21:05:18 +08:00
yml2213	ed6e186655	fix(ui,test): 说明巡检与重登的联动关系；修掉一条按分钟偶发失败的测试 ... 看图时发现两个问题： 一、页面上那段说明是 P1a 时代的文案，已经过时且误导：「重登仍由人工在 「CK 检测与重登」页面操作」——P1b 上线后自动重登已存在。两个作业其实是联动的 上下游：巡检把账号标成 invalid，「CK 自动重登」的候选条件正是这个字段，所以 巡检一发现失效、重登作业下一周期就会接手。刻意分成两个作业是为了止损粒度 （巡检只读零风险；重登会真实登录，出问题可单独关掉）。据此改写说明文案，并在 两张卡片上标出「下游：CK 自动重登」/「上游：巡检标记为失效且有 CK 的账号」。 二、jobs 接口新增 pending_relogin：当前有多少条正等着自动重登。页面靠它把 上下游关系显性化 —— 没有这个数字，两个开关看起来像互不相干。计数走重登作业 自己的候选查询，保证「页面显示的待办」和「作业实际会捞的」是同一口径。 顺带修掉 tests/test_douyu_email_code_pick.py 里一条既有缺陷：它用 max(0, now.minute - 30) 构造「30 分钟前的邮件」，分钟数小于 30 时会退化成当前 整点（21:00:12 → "今天 21:00"），只比 now 早十几秒，于是断言随「当前几点」偶发 失败 —— 每小时前 30 分钟必红（已确认在我本次所有改动之前的提交上同样失败， 不是本次引入）。改成真实的时间减法，跨天时用「昨天」。 全量 298 通过。提交时另一路 SQLite→MySQL 的测试改造仍在同一工作区进行， 本次只暂存本功能相关文件。	2026-10-02 21:01:17 +08:00
yml2213	8fc8e623b9	feat(automation): CK 自动重登（P1b）+ 失败分型与待人工队列 ... P1a 的巡检只产出「谁失效了」的清单，不兑现修复：1,356 个失效账号仍要人工逐个 选集→点重登→过滑块。线上实测 20 个失效账号重登 20/20 成功（2 分 13 秒、零极验）， 证实失效是会话级过期而非凭证问题，可救量约 1,350。 后端： - 迁移 20261002_0038：login_tasks 加 relogin_failure_kind（枚举），供作业决定 「继续退避重试」还是「转人工」；不用 attempt_message 做字符串匹配（文案一改 就失效，页面也要按类型筛选）； - jobs/ck_relogin.py： - 候选 = 巡检判定 invalid + 允许自动管理 + 无在途尝试 + 退避到期 + 未超每日上限 + **未转人工**（极验/凭证问题不再自动重登）； - 复用 LoginBatchRunner(mode="relogin")，成功才替换 CK（沿用既有安全语义）。 自动化身份取最早的超管做 created_by，权限给 login:view_all 以免受归属限制； 总时长上限压到 240 秒，避免长时间占住调度线程； - settle_results() 独立成纯函数便于单测：成功清空退避状态；失败按分型分流 —— captcha/credential 转人工（不排期）、email_quota 退避到次日零点+随机抖动、 email_code/interrupted/network 走 1h→3h→12h→24h 阶梯；次数用尽也停下等人工； - 未知文案默认按可重试处理（有每日上限兜底），别把可能只是抖动的账号推给人工； - 注册第二个作业「CK 自动重登」（batch 10 / 并发 3，**默认关闭**）； - 新增 GET /api/automation/manual-queue：按原因分组列出待人工处理的账号。可重试 类型但已无下次排期的（次数用尽）单独成组 —— 否则会混进「验证码失败」里，客服 看不出这个已经不会再自动试了。 前端： - /automation 页新增「待人工处理」卡片，按分型分组展示（极验要过滑块、凭证要核对、 次数用尽要人工确认），各带账号与最近失败原因。 测试：新增 26 条（分型顺序陷阱「上限」优先于「验证码」、退避阶梯、配额退避次日、 候选筛选、MySQL 方言编译、结算、待人工队列分组）。 提交前全量 297 通过、ruff 全绿、前端 tsc 通过。 注意：提交时另一路「测试改用 MySQL」的改造正在同一工作区进行，本次刻意只暂存 本功能相关文件，未触碰 tests/conftest.py、tests/support/ 及对方已转换的测试文件。	2026-10-02 20:51:19 +08:00
yml2213	f8c5e896d4	fix(automation): 巡检区分「查不到」与「失效」，并在大面积失败时自动暂停 ... P1a 原本把「检测没通过」一律写成 invalid。但 check_douyu_cookie 的失败分两类： 斗鱼明确回「未登录/登陆异常」（CK 真失效），以及请求超时/响应异常（我们查不到）。 一视同仁的后果是：斗鱼接口抖动或被风控时，每 5 分钟 200 个、一小时就能把两千多个 好账号标成失效，客服会误判成「CK 大面积挂掉」。规划里的失败率熔断只给了 P1b， P1a 漏了。 改动： - 新增 classify_result()：valid / invalid（命中斗鱼鉴权类说法）/ error（其余）； - error 时**不覆盖该行原来的 ck_check_status**，只更新 ck_check_result（带 verdict 字段）与 ck_checked_at，并计入本轮 skipped； - 一轮 error 占比 > 30% 且条数 >= 20 时自动把作业 enabled 置 false，message 与 detail.paused 写明原因，避免继续污染； - 真实死号占比高**不触发**暂停 —— 首轮 100% invalid 是预期情况（选行「从没检测过 的优先」，积压的是两个月前批量导入、attempt_status 为空、从未登录的陈旧账号， 生产实测 200 条错误信息一致为斗鱼侧「用户未登录」）。 新增 6 条测试：分类正确性、error 保留原结论、异常不再标失效、大面积失败自动暂停、 真实死号不暂停。全量 271 条通过。	2026-10-02 20:35:30 +08:00
yml2213	65a4590291	refactor(time): 时间列统一走 UTCDateTime，并把 MySQL 会话时区对齐成 UTC ... 问题不是「UTC 还是本地时间」，而是这套口径有两个半吊子的地方： 1. 库里存 naive UTC、读出来也是裸时间，于是每一处比较/输出都得自己补时区。 项目里因此散了三份 _as_utc 和一堆 replace(tzinfo=UTC)，P1a 排下一轮时间 时还炸过一次 TypeError: can't compare offset-naive and offset-aware。 2. MySQL 会话时区跟随系统 +08:00，而库里存的是 UTC —— SQL 里的 NOW()/ CURDATE() 比库里的时间快 8 小时，查询会静默返回空（P1a 排查时就遇到过， 看着像「没有数据」）。 改动： - 新增 database.UTCDateTime：写时 aware→转 UTC 去 tzinfo、naive 视为 UTC； 读时一律补 UTC 时区。底层 DDL 仍是 DATETIME，**不需要迁移**。models.py 的 28 个时间列全部改用它，模型上的时间字段从此不再是裸值； - docker-compose 给 mysql 加 --default-time-zone=+00:00，让 SQL 时间函数与存储 口径一致。安全性已核实：全库 0 个 TIMESTAMP 列、0 个 CURRENT_TIMESTAMP 默认值，改这里不会改变任何已有数据的语义； - 新增 tests/test_utc_datetime.py：读出必须 aware、能直接和 datetime.now(UTC) 比较、带 +08:00 的写入要落成 UTC、naive 写入视为 UTC，并有一条元测试扫描 Base.metadata，防止以后新增时间列忘了用 UTCDateTime。 保留既有的 _as_utc 补丁（对 aware 值是幂等的，属防御性代码）；新代码不再需要。 「存 UTC、算 UTC、显示本地」三条线至此各自明确：存储与比较统一 UTC，日志按 容器 TZ 显示本地时间，前端 formatTime 负责转本地。	2026-10-02 20:27:07 +08:00
yml2213	3d5d0f551f	fix(automation): 去掉 MySQL 不认的 NULLS FIRST，排序改用可移植写法 ... 生产 MySQL 上手动跑第一轮就报 1064： You have an error in your SQL syntax ... near 'NULLS FIRST, login_tasks.id ASC' NULLS FIRST 是 PostgreSQL/SQLite 语法，MySQL 不支持。本地测试全绿是因为跑在 SQLite 上（它认识这个语法），属于方言差异漏网 —— 生产是 MySQL、测试是 SQLite， 行为测试覆盖不到这类问题。 改成 `ck_checked_at IS NULL DESC, ck_checked_at ASC, id ASC`：三个方言下语义 一致（没检测过的优先）且都是合法 SQL。顺带把选行查询抽成 build_select_query， 便于按方言编译做回归。 新增回归测试：用 MySQL 方言 compile() 选行 SQL，断言不含 NULLS FIRST/LAST， 且「没检测过优先」用可移植写法表达。 规划附录 C.2 记下这条：写 SQL 前先确认方言；P0 连的是 order_site 的 PostgreSQL， 项目里已经出现 MySQL / SQLite / PG 三套方言。	2026-10-02 20:14:49 +08:00
yml2213	7aaaeebe2b	fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔 ... P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是 作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过 一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。 按规划原意修正： - TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮； - next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds； - interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就 是这么用的，无需改）； - 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟， 冷启动约 5.4 小时覆盖全库，稳态每轮一百多条； - 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清 「每 5 分钟跑一轮」，避免运维误以为是作业周期。 同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线 步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。	2026-10-02 19:54:31 +08:00
yml2213	f745a61df1	feat(automation): CK 自动巡检（P1a），只检测不改 CK ... 后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。 P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、 把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里 「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。 实现： - 迁移 20261002_0037：automation_jobs / automation_runs 两张表， login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error （为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）； - services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库 （重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关 也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置； 作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁； - services/automation/jobs/ck_health.py：选行口径与人工检测一致 （cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、 auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）； 只写 ck_check_status / ck_check_result / ck_checked_at； - routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、 GET /runs；新增权限点 automation:view（运营可看）与 automation:manage （仅超管），改配置与手动触发都写审计； - 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）； - 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、 「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。 验证： - 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、 选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条 专门断言巡检后 cookie/status/message/attempt_status 一字未动； - 全量 257 条通过；前端 tsc 与构建通过； - 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie 逐条一致（3/3 valid），CK 与尝试状态全程未变。 顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与 datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。	2026-10-02 19:47:41 +08:00
yml2213	168421b40c	fix(douyu): 恢复二维码常驻显示，绑定类任务终态也要能看到码 ... 上一版加了「任务进终态后隐藏账号列表里的小二维码」，但绑定类任务等不到扫码 时会以 success 收尾（douyu_runner_bind: "已生成绑定二维码，未检测到新扫码 角色"），url 仍在结果里，码却被藏掉，客服再也点不开 —— 绑定/电竞绑定/小店 绑定都受影响。 二维码的意义与任务终态无关：只要 result 里还有地址就一直显示。这里恢复 taskQrUrl()，删除 activeTaskQrUrl 与 QR_TERMINAL_STATUSES。 「开通时二维码闪一下就变小」不会复发：根因是支付弹窗被自动关闭 + 已开通账号 被误判到账，现在弹窗不再自动关，且已开通账号在开通前就被拦下、根本不生成 支付码。	2026-10-02 09:14:40 +08:00
yml2213	99db772ddd	feat(douyu): 精英宝典支持查询开通状态，开通前先校验且不再误判到账 ... 线上两个问题：工作台看不到账号有没有开通精英宝典；点开通时二维码会「闪一下 就变小」——大图弹窗 2~4 秒后自动关闭，只剩列表里 56px 的小二维码。 根因： - getUserInfo 的 manualType/expireTime 才是开通状态的权威口径，但只有兑换 流程用过一次，没有任务类型对外暴露；前端只看积分列，而「开通后积分花完」 和「从未开通」都是 0 分，区分不了（实测 13456 manualType=1/score=0）； - 开通前不查状态，且到账判定写成「积分 >= 300」：账上本来就有 680 分的账号 在出码后第一轮轮询就被判成功，前端按 paymentArrived 自动关掉了弹窗。 改动： - 新增任务类型 query_elite_status：查 manualType/manualScore/expireTime 并 落库到 accounts.elite_opened / elite_expire_time（迁移 20261001_0036）， 精英工作台加查询按钮与「宝典状态」列（已开通+到期 / 未开通）； - create_elite_qr 开通前先查状态：已开通直接判成功、不再生成支付码（方案 A）， 既消除二维码闪现，也避免给已开通账号开出真实支付单； - 到账判定改为「积分比开通前增长」，基线用与轮询同源的 credit/balance 取， 取不到基线才退回旧口径； - 支付弹窗不再自动关闭：到账/失败/停止都在弹窗里给结论 + 手动关闭；列表小 二维码在任务进终态后隐藏。 新增 9 条测试覆盖上述行为，回退 runner 时其中 8 条失败。	2026-10-01 19:08:25 +08:00
yml2213	6a25097412	fix(douyu): 替换 CK 是最后一步，只有登录成功才写回记录 ... 上一版把可见性改成「记录里还有 CK」，账号不会再消失，但根因还在：批次启动 时就把复用的成功记录改成 pending（旧 CK 仍在），停止或失败后没人恢复状态， 记录一直显示成一次没完成的登录。 按「替换 CK 是最后一步」把两者拆开： - login_tasks 新增 attempt_status / attempt_message / attempt_batch_id / attempt_at，批次只写 attempt_*，status/cookie/message 只在登录成功时更新； - _begin_attempt 只登记尝试，_mark_attempt_failed 只记录失败（已有 CK 的记录 原样不动），_write_login_success 是唯一替换旧 CK 的入口； - 停止批次、代理不可用、登录异常、进程重启清理全部改为收敛 attempt_*， 因此停止一个批次不可能再让账号失去 CK； - 复用的记录改用「持有 CK 的记录」，不再创建第二条记录，失败记录在无 CK 时 才复用； - 登录任务列表/统计按 attempt_* 展示「这次登录怎么样了」，批次筛选同时匹配 attempt_batch_id；CK 操作页的重登状态也从 attempt_* 映射； - 迁移 20261001_0035 归一存量数据：持有 CK 的记录 status 统一为 success、 历史状态搬进 attempt_*，无 CK 且卡在 pending/running 的收敛为 failed。 新增测试：批次失败/停止不碰旧 CK、成功后替换 CK、列表展示尝试状态、 迁移存量数据归一。	2026-10-01 18:29:49 +08:00
yml2213	64c399617a	fix(douyu): 账号只要还持有 CK 就不再从工作台消失 ... 线上事故：分配给客服的账号（如「远行者103」）在斗鱼工作台与 CK 列表里 查不到，只有账号管理里还能搜到。原因是可见性判定写成了 LoginTask.status == "success"，而按设计保留旧 CK 的三种状态都不再是 success： - 普通登录批次启动时会把复用的成功记录置为 pending/running（旧 CK 保留）， 批次被停止或失败后一直停在 pending，账号永久消失； - CK 重登失败置为 relogin_failed（旧 CK 保留），账号从工作台消失； - 普通登录失败置为 failed（复用记录的旧 CK 未清空），同样消失。 线上现状：12545 个账号持有 CK，但只有 11703 个能出现在工作台，842 个 （644 重登失败 + 176 排队中 + …）对客服和管理员都不可见。 改动： - douyu_service 新增 cookie_holding_filter()/latest_cookie_login_task()， 以「记录里还留着 Cookie」作为唯一判据，并抽出 LOGIN_IN_FLIGHT_STATUSES 与 cookie_operable_filter() 供检测/重登入口复用； - 斗鱼工作台账号列表、任务账号校验、账号管理 has_cookie 筛选、分配校验与 概览、CK 管理/操作列表、首页 CK 统计统一改用该判据； - 工作台取 CK 从 latest_success_login_task 换成 latest_cookie_login_task， 保证重登失败/排队中的账号仍能被任务正常执行； - 新增 cleanup_orphan_login_tasks()：进程重启后把遗留的 pending/running 收敛为 failed 并保留旧 CK，避免页面永久显示排队中。 新增回归测试覆盖上述状态下的可见性、可执行性与启动清理。	2026-10-01 18:18:02 +08:00
yml2213andCursor	4806d4bbf1	feat(douyu): 精英宝典导入支持按多行账户名筛选 ... 对齐 Cookie 自定义 CK 的粘贴导入方式，按账户名精确匹配并保持粘贴顺序。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-29 15:02:53 +08:00
yml2213	1ac6a13a2c	fix(audit): 修复审计日志时区差并支持供应商单号搜索与展示 ... - 解决审计日志 8 小时时区差：后端输出带时区 UTC ISO 字符串，前端 formatTime 增加 UTC 自动解析换算 - 审计日志支持单号检索：list_audit_logs 关联 DouyuTask 匹配供应商单号、外部单号、UID、昵称等 - 列表摘要与详情抽屉优化：摘要直观展示供应商单号与外部单号，抽屉增加专用供应商订单列表并支持一键复制 - 增加测试用例覆盖时间格式与单号反向检索	2026-09-12 14:52:26 +08:00
yml2213	4518b726ac	feat(huya): 浏览器兑换三目标直达并收窄扩展注入范围 ... - 操作列改为「直播间 / 精英宝典 / 电竞宝典」三个直达按钮，点哪个就按哪个目标写入登录态并打开，去掉弹窗内选择 - 新增 services/huya_exchange_targets.py 统一三个目标地址，接口支持可选 body {"target": "..."}（不传=精英宝典） - 扩展内容脚本从 <all_urls> 收窄到后台站点白名单，service worker 校验 sender.tab.url，拒绝其它来源的注入 - 注入改为 Cookie 写完后回执（ok/written/failed/error），前端按回执提示成功或失败，不再静默 - 扩展图标兜底改用 world:'MAIN' 读取；一个 Cookie 都没写成功时不打开目标页 - 兑换材料签发写审计 huya:exchange:kit（含账号与目标） - 控制台脚本增加 huya.com 域校验与 Secure，与扩展路径保持一致 - 修复兑换记录轮询的跨账号串扰与卸载后 setState；兑换请求加 epoch 防止过期结果覆盖弹窗 - 新增 tests/test_huya_browser_exchange.py（13 项）并同步 docs/HUYA_BROWSER_EXCHANGE.md	2026-09-11 10:31:46 +08:00
yml2213andCursor	874a95dd6f	chore: 提交和推送前增加前端 TypeScript 检查 ... 与 Docker 构建的 tsc -b 对齐，避免类型错误在服务器构建才暴露。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-10 11:45:35 +08:00
yml2213andCursor	c1f4e7c7ae	fix(huya): 修复账号页登录队列状态比较导致的前端构建失败 ... Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-10 11:42:41 +08:00
yml2213andCursor	e0810a9c0b	style: 按 ruff 格式化登录队列代码并跳过已删除文件的推送检查 ... Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-10 11:32:29 +08:00
yml2213andCursor	e81119117f	feat(huya): 多选登录改单线程队列并拆分路由与工作台 ... 默认同时只登一个号，失败两次跳下一个，号间留间隔，结束后可一键重试失败账号。 顺带拆分虎牙路由与斗鱼工作台页面，并补齐 raw_cookie 重建入口。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-10 11:31:50 +08:00
yml2213	8dea9e3244	style(huya): 全面重塑虎牙账号管理页面UI视觉与交互体验	2026-09-06 14:08:51 +08:00
yml2213	cbc7f7c9c5	fix(huya): 优化账号密码导入交互并将导入类型严格限制为四段格式 ... - 交互优化：将账号标签选择器移至弹窗顶部，避免下拉列表向下展开时遮挡底部的'确定'/'导入'按钮 - 格式限制：严格限制仅允许'账号----密码----手机号----接码链接'四段格式导入 - 前后端校验：前端逐行校验格式并提示具体错误行号，后端限制 require_four_segments=True 兜底	2026-09-06 14:00:24 +08:00
yml2213	d3005478a9	feat(huya): 支持四段式账号导入接码及旋转/文本点选多级验证码闭环过验 ... - 账号导入：支持'账号----密码----手机号----接码链接'四段式解析与持久化存储 - 旋转验证码 (rotate_auth / xz)：逆向分析官方协议，基于圆周边界采样互相关算法秒级计算旋转还原角度 - 文本点选验证码 (dx_auth)：内置成语与古诗名句语料，支持题干菜名提取与古诗/成语挖空正则求解及小图动态合成 - 短信二次验证 (sms_auth2)：结合 sms_url 自动轮询接码链接并 Hex 编码提交官方过验 - 前端交互：增加接码标签、在线查询短信验证码、一键自动短信登录与测试接码链接功能 - 回归测试：新增旋转验证、短信接码流与文本点选测试用例（173 passed）	2026-09-06 13:56:44 +08:00
yml2213	4f9a6864eb	优化验证码展示	2026-09-06 13:02:37 +08:00
yml2213	8309072120	统一推送前Python代码格式	2026-09-05 19:25:46 +08:00
yml2213	90a0065918	虎牙菜单按角色显示并修复确认框暗色模式 ... 客服在虎牙导航只显示浏览器兑换，管理员/运营保留完整入口；退出登录 与显示凭据确认框改用 App.useApp() 的 modal 实例以适配暗色主题； 版本号升至 0.3.0。	2026-09-05 19:21:59 +08:00
yml2213	178eba1eea	浏览器兑换独立成页面并按斗鱼模式优化导入 ... 新增 /huya/browser-exchange 页面（精英宝典下方），支持导入账号与 执行兑换，客服仅见已分配账号；账号管理页移除该功能。导入弹窗对齐 斗鱼操作台：服务端分页筛选、可搜索标签、无 CK 不展示、导入本页/ 一键导入全部/导入选中；新增 /accounts/ids 接口与 workbench browser_exchange scope。	2026-09-05 18:30:29 +08:00
yml2213	230d6c1918	虎牙人工兑换改用本机浏览器并新增扩展自动注入登录态 ... 移除服务器浏览器方案（容器/Xvfb/noVNC/CDP 会话管理），后端仅下发 兑换材料；新增内置 Chrome/Edge 扩展一键写入 huya.com 登录态， 未安装扩展时回退控制台脚本手动注入，兑换始终由用户手动完成。	2026-09-05 17:55:31 +08:00
yml2213	2a1b1e642c	优化虎牙精英宝典工作台与Cookie生成	2026-09-02 12:48:41 +08:00
yml2213	61eb434138	双份cookie存储：raw_cookie 保存App原始凭据，与网页运行ck分离 ... 网页运行ck（cookie列）含本地随机生成的网页设备字段，若被风控标记 无法还原纯净登录凭据；新增 raw_cookie 保存16字段App原始态，供 设备态重建/审计/复核登录有效性。 - HuyaAccount 加 raw_cookie 列（alembic 0034，MySQL TEXT nullable） - HuyaLoginResult 加 raw_cookie 字段；App登录链补齐前快照原始凭据 - upsert_huya_cookie 支持双写；app-password-login 路由透传 raw_cookie - 存量行 raw_cookie 为 NULL（老账号无快照），新登录自动填充	2026-09-01 23:15:20 +08:00
yml2213	727c32a5f5	接入匿名设备态协议补齐Cookie字段并放宽保存	2026-09-01 19:29:56 +08:00
yml2213	48c37bb8d7	虎牙网页Cookie来源驱动合并与WSS传输门禁	2026-09-01 19:17:32 +08:00
yml2213	26514b332d	完成虎牙宝典WSS绑定与快照隔离重构	2026-09-01 12:40:22 +08:00
yml2213	90ce72fa15	隔离虎牙宝典批量任务WSS会话	2026-09-01 12:25:03 +08:00
yml2213	2fca1210bb	切换虎牙宝典活动任务到WSS会话	2026-09-01 12:23:43 +08:00
yml2213	aab84e0fb5	切换虎牙宝典开通任务到WSS会话	2026-09-01 12:20:58 +08:00
yml2213	eb065a7c77	接入虎牙精英宝典最新商城前置流程	2026-09-01 11:42:52 +08:00