Archived
133beab492e0bef0ecef0c87329860ee25a5a9cd
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 snowy-yang
|
69a50c2c31 |
refactor: worker 子系统全面异步化，拆掉同步转异步的桥接层
拆掉「同步调异步 / 异步桥同步」两类垫片的第二半（HTTP 线 B2 见前序提交）。 worker 侧此前是「起线程跑同步函数、函数体内部再用 asyncio.to_thread 把活塞给 另一条循环」——线程与协程互等，取消/暂停只能靠轮询。本轮把 worker 自身变成 协程，由 _start_task 直接挂到应用事件循环上，桥接层随之失去存在理由。 改动（按子系统）： - music_downloader：downloader / _aria2 / _concurrency / cover / _http / __main__ 全链路协程化。per-file 锁改 asyncio.Lock；计数闸改 「active 计数 + await asyncio.sleep(0.5)」的可取消等待（原阻塞式 with 会让 已取消任务仍要等全局名额腾出，卡死并拖后腿退款）；aria2p 的同步 RPC 仍经 to_thread，轮询改 asyncio.sleep；新增 core.http_client.iter_chunks，把**流式 读取期**的 aiohttp.ClientError 收敛成 UpstreamNetworkError（请求建立阶段早已 有这条路径，读取阶段此前没有，断流会绕过调用方的 UpstreamError 分类）。 删除 get_http_session / _SESSION_LOCAL。 models._RetryFromScratch 不再继承 requests.RequestException 而继承 Exception： 它是「续传起点失效、残片已清、从头重下」，既不是确定性失败 (DownloadException)，也不是残片已保留的网络失败(UpstreamError)，必须独立 成类且在 except 链中先于二者捕获。 - music_api：podcast.py 全部函数协程化（直链解析内部改 await NeteaseAPI.get_song_url）；compat.py 删除——16 个死掉的同步门面早已 清空，文件只剩空壳。 - services：_taskcore / _zipcore / batch / downloads / podcast / tasks 协程化。 threading.Thread → loop.create_task（任务句柄字段 worker_thread → worker_task），ThreadPoolExecutor → asyncio.gather + asyncio.Semaphore， 终态函数与结算回调全部改 await；监控线程里「worker 已死」判定改 task.done()。 删除 services/streaming.py（同步流垫片，唯一消费者已迁到 core.http_client.open）。zipfile 实例仍非线程安全，故「下载」并行、 「入包」严格串行。 - web：路由层 130+ 处 to_thread 拆除——被包住的目标自己已是协程，再包一层只是 把协程丢进线程里跑一圈。tasks_registry.start_task 直接 create_task。 web/app.py 关闭段去掉 async_bridge.shutdown()（不再有第二条约循环）。 web/routers/download.py 的播客端点补上 3 处漏掉的 await （extract_podcast_ref / get_radio_detail）——漏掉时不报错、只静默返回协程对象， 靠 pyright 抓出来后修正。 留在 to_thread 上的都是**正当的阻塞卸载**：同步 SQLite 落库与账本结算、 mutagen 全量重写标签、zipfile 整段拷贝、shutil.rmtree、aria2p 的同步 RPC、 PBKDF2 的 10 万次迭代。ruff 对残留的本地元数据操作（exists/stat/os.replace/ 往 .part 顺序写分块）按「微秒级、卸载的调度开销大于操作本身」放行，pyproject 逐条注明理由。 取消/暂停仍由 threading.Event 承载：置位方是请求线程/监控线程，读取方是 worker 协程，只有「置位」与「轮询读取」两种操作，既不需要跨循环唤醒也不会卡住事件 循环——比 asyncio.Event 更省心（ASYNC110 同理按此豁免）。 测试：10 个文件的替身边界同步迁移——网络替身从 core.sync_http 的 get_http_session 换成 downloader/服务模块的 _http.open + **真实** iter_chunks （顺带钉住读取期异常收敛）；`_run` 改为在独立线程里 asyncio.run(worker(...))； aria2 的假时钟从 time.sleep 换成 _POLL_INTERVAL=0；monitor 的线程句柄替身换成 done() 可控的轻量替身（asyncio.Task 的构造需要运行中的事件循环，而监控循环跑在 常驻线程里）；podcast / 封面 / 结算包装等替身一律改 async。 门禁：ruff 全过 / pyright 0-0 / pytest 383 项全绿（0 失败）。 下一步 B2：auth_system 12 个模块改 aiosqlite 背板、web 层剩余 to_thread 收尾； B3：删 core/sync_http.py、core/async_bridge.py、core/http_errors.py（现仅 sync_http 自用）。 |
||
|
snowy-yang
|
da83201403 |
refactor: run_zip_job 四路终态收尾拆解（167 行 / 圈 37 → 32 行 / 圈 5）
为什么：run_zip_job 是全仓圈复杂度最高的函数（37），167 行里四个终态——正常交付、
全部失败、取消（含部分交付/全额退两条支路）、异常（同样两条支路）——各写一段
8~20 行的收尾内联在 try/except 里，且都伸手去读同一批局部变量。上一轮抽这个引擎时
就已指出「还可以再拆」，当时为控制单次改动面留了下来。
改法：把「一次运行」的状态收进 _ZipRun，四个终态各自成函数。
_ZipRun job / task_id / settle / tally / task / params /
cancel_ev / pause_ev / items / zip_tmp_path / zip_valid / t0
_progress_of 构造进度回调（原先是个内嵌闭包）
_start_zip_run 置 running + 组装清单 + 写 total + 计费补扣
_build_zip_archive 建临时 ZIP + 逐窗口填充 + 置 zip_valid + 记耗时
_publish_delivery 正常交付（结算 → 锁内复查 → 发布 result → on_delivered → 日志）
_finish_all_failed 全失败（丢弃空包 + 全额退费 + 转 error）
_finish_canceled 取消（部分交付 / 全额退两条支路）
_finish_business_error DownloadException（保留我们自己拼的用户可读文案）
_finish_unexpected 通用异常（先落 traceback 再泛化文案，两条支路）
复杂度（同口径 AST 实测，HEAD 与工作区由同一脚本测出）：
run_zip_job 167 行 / 圈 37 / 嵌套 4 → 32 行 / 圈 5 / 嵌套 2
文件内最大圈复杂度 37（就是它） → 13（_fill_zip，本次未动）
文件行数 439 → 522（+83，全是新签名与 docstring）· 函数数 19 → 27
顺手消掉一个**隐患**，不是纯搬家：``zip_valid`` 原先必须手工在函数头初始化为
False（注释写明「漏了就 NameError 二次崩线程」——它正是上上轮那个 bug 的残留
护栏）。收进 dataclass 后该约束由构造函数承担，而 ``_ZipRun(...)`` 的默认值就是
假值，物理上写不出「忘记初始化」。
等价性证据（两道，互相独立）：
1. 不靠注入脚本，直接把文件还原成 HEAD 版跑同一套测试（git stash push 单文件 →
跑 → pop）：tests/test_zip_workers.py + test_monitor_jobs.py 共 33 例**全过**。
这批测试是上一轮用反向注入验证过「忠实编码旧行为」的，故本轮它们对新实现
构成等价性验证。
2. AST 字面量多重集比对：字符串 56 种**一个不少**——没有任何用户可见文案或日志
格式被动过。数值唯一差异是 `0.0: 0 → 1`，即 _ZipRun.t0 的字段默认值。
刻意保留的语义（是决定，不是疏漏）：
- _publish_delivery 里「先 settle 再抛 DownloadCanceled」的顺序原样——抛出去后
_finish_canceled 会**再 settle 一次**（delivered 口径不同），依赖的是 ledger_settle
幂等；原实现同样如此，未动。
- 取消与异常两条支路里「部分交付」与「全额退」的判定条件（`delivered > 0 and
zip_tmp_path`）逐字保留。
- _finish_all_failed 不走 _apply_error：它要额外记 failed 计数，口径与 error 支路
不同（原实现即如此）。
- record_duration 仍在 zip_valid 置位之后、全失败判定之前（保持原顺序）。
验证：ruff 全过 · pyright 0/0 · pytest 294 passed（与改动前同数）· 生产 data/ 未被
触碰（全部用例走 tmp_path 沙箱）。
|
||
|
snowy-yang
|
5c8f941d19 |
refactor: 两个 ZIP 打包 worker 合并为一个参数化引擎（604 行重复骨架 → 一份）
为什么：_batch_zip_worker（327 行 / 圈 78 / 嵌套 9）与 _podcast_zip_worker
（277 行 / 圈 84 / 嵌套 9）是两份平行实现——任务状态机、断线暂停、全局批量
名额、「逐条失败不计整批」、取消与异常的四路终态收敛、账本结算全部各写一遍，
连注释都逐字重复。上一轮修的 zip_valid 未绑定缺陷正是同型出现在这两处，
重复代码在持续制造同类 bug。
改法：新增 services/_zipcore.py 只保留共用骨架，差异收敛到 ZipJob 钩子：
prepare / download_one / write_entry / zip_filename 必实现，prefetch /
fail_label / done_msg / log_label / all_failed_msg / partial_msg / supplement /
on_delivered / cleanup 按需覆写。batch.py 与 podcast.py 只剩薄包装 + flavor 类。
线程模型（改动中最容易踩坏的一条，已写进模块 docstring）：
ZipFile 不是线程安全的，且包内名去重是「读改写 used_arcnames」。因此把下载与
落包拆成两个钩子——只有 download_one 进线程池，zf.write 与去重一律在调用线程
串行。旧的音乐批量之所以安全，只是因为它的 zf.write 恰好写在主线程的
as_completed 循环里；照搬成「整个下载单元进池」会引入静默的 ZIP 损坏。
复杂度（同口径 AST 实测）：
两个 worker 合计 604 行 / 圈 162 / 嵌套 9,9
→ run_zip_job 167 行 / 圈 37 / 嵌套 4
+ _fill_zip 64 行 / 圈 13 / 嵌套 5
全仓最大圈复杂度 84 → 37；>80 行函数 3 → 2（余下两个之一是本次未改动的
_podcast_download_worker）。两文件改为三文件后总行数 930 → 1071，多出的
主要是引擎 docstring——注释比代码贵，但它把「为什么这么拆」留给了下一个人。
逐条对齐的分叉（合并必须做的决定，此处全部列明）：
1. 账本终态：播客全失败走自己的 except DownloadException → 落 'settled'，音乐
同语义事件落 'error'。统一为 'error'。全仓仅读取 'open'（对账/清理/计数），
其余取值只作排障留痕 → 这是本次**唯一可观察的语义变更**，由新增用例固化。
2. 通用异常路径的「部分交付」：音乐侧会发布已打包的 ZIP 并挂 result，播客侧
直接丢弃（却已按 delivered 结算 = 用户扣了费拿不到货）。统一采用音乐侧口径。
该路径实际不可达（ZIP 写完后到发布前只有取消检查会抛错，已被取消分支接管）。
3. 全失败判定：音乐用 `ok == 0 and failed`、播客用早抛 DownloadException。
统一为显式 `ok == 0`——好处是不再发布空 ZIP、不再把空批次标 done。
4. 早抛业务失败（无可下载条目 / 补扣失败）：播客走 DownloadException 分支，
音乐无此分支（落通用异常，用户看到的是「打包失败，请稍后重试」）。统一保留
该分支，音乐侧同类失败从此也给出具体原因。
5. 错误终态写法：播客在手写任务字典（重复一遍「已终态不覆盖」，且漏掉 /F-E 的
「worker 线程已死则按账本补结算」兜底），统一走 _mark_task_terminal。
6. 暂停检查点：统一采用音乐侧更严的一处——拿到 BATCH_ZIP_SEM 后再查一次
pause/cancel。播客此前会多下完一集才停。
7. total 字段：音乐由提交侧设置、播客由 worker 设置，统一为 worker 设
len(items)（对音乐是同一个值）。
8. 日志文案统一（tag / 名词提成类属性）：'批量打包异常' 与 '批量ZIP任务异常'
两种前缀收敛为一种；完成日志统一带上 task_id 与退回次数。
删除的不可达分支（可证明）：
两个 worker 在 zip_valid = True 之后各留了一段 `if not zip_valid:` 失败收敛
（音乐 16 行 / 播客 18 行，含「ZIP 打包失败（可能磁盘空间不足）…」文案）。
赋值紧跟其后、中间无任何语句可改写 zip_valid，故恒不可达——是原注释所称
「复审 修正」留下的护栏。zip_valid 在异常路径仍有意义（决定 delivered 是否为 0）。
等价性证据（三道，互相独立）：
1. AST 字面量多重集比对 + 逐条位置定位：数值 16 种一个不少。少掉的 8 处 `0`
全部来自上面删的不可达分支与重复字面量合并（`delivered = … else 0` 5 处→3 处）。
2. 反向注入验证：把 git HEAD 的旧 worker 注入成 services.batch / services.podcast，
用同一套 tests/test_zip_workers.py 去跑 → 第 1 批 9 例行为契约**全过**，证明
这套测试忠实编码了旧行为、因而对新实现构成等价性验证；新增 4 例中只有账本
终态那 1 例失败（'settled' == 'error'），恰好把上面第 1 条对齐实证出来。该用例
里「全部单集下载失败: …（已退回 2 次下载次数）」的文案断言在旧实现上也通过
→ 用户可见文案逐字保留。
3. 新增 4 例固化测试：同名歌声的音频/歌词/封面三条目共享序号后缀（F-C）、
两边的全失败文案与账本终态、单集失败后任务目录不留中间文件与 .part 残片。
顺带修掉一个自己引入的缺陷：引擎化后播客侧的单条失败文案本会退化成整个条目
字典，字面量审计里 '(' ')' 各少 1 处把它逼了出来 → 补 ZipJob.fail_label 覆盖。
验证：ruff 全过 · pyright 0/0 · pytest 213 passed（209→213）· 生产 data/ 未被
触碰（全部用例走 tmp_path 沙箱）。
|