 AskaEth
|
1004af81ca
|
fix(download): 同源换表示时不再沿用上一份的校验器 + 三条 p3 收口（M293 r2）
复审 r2（p2-1）：r1 的 `same_source` 只挡了「源不同」，没挡「同一 URL、换了一份表示」。
`done` 为空（Restart：`SizeChanged` / `HashChanged` / `ChunkLayout` …）时没有任何字节要接着用，
但 `journal.begin` 仍把上一份表示的 ETag 写进**新一轮**元数据；`record` 又只在缺值时写 ⇒ 本轮
3 段（新内容）配的是旧校验器 ⇒ 重试拿它发 `If-Range` ⇒ 服务器按 RFC 7233 回 200 + 完整正文 ⇒
`RangeUnsupported` ⇒ 丢整份 ⇒ 单连接从头下。实测 113664 字节（2.775×），比「干脆不续传」的
72704（1.775×）还多一整份。
修法：「谁能当校验器」收成一个 `carry`，两个维度缺一不可 ——
let carry = if done.is_empty() { None } else { same_source };
`if_range`、`etag`、`last_modified` 三处全部走它。清掉之后本轮响应里的真实校验器由
`ChunkJournal::record` 填进来；最坏也只是 `NoValidator` ⇒ 整份重下（1.775× 基线），不会更坏。
文档（`chunk_resume` 模块头的「校验器跟着源与表示走」、`record`、`carry` 处）同步改成两维口径。
判据（新用例 `chunked/resume.rs::stale_validator_from_the_previous_representation_is_not_carried`）：
同一 URL、盘上是上一份表示的元数据（旧总长/旧段区间/旧 ETag `"v1"`/旧摘要）⇒ 本轮因
`HashChanged` 走 Restart、服务器此刻发 `"v2"`。断言：重试的 `If-Range` 只许是 `"v2"`、字节数
41984（1.025×，而不是 113664）、hits 5、resumed_from 30720、终态文件逐字节正确。
变异（两种，均实测红）：
* 只把元数据那两行退回 `same_source`（`if_range` 仍按 `done` 门控）⇒ 复现复审的探针数字：
PROBE stale_validator if_range=["\"v1\""] hits=6 bytes=113664 resumed_from=0，
断言红在 `left: ["\"v1\""] right: ["\"v2\""]`；
* 把 `carry` 整体退回 `same_source`（连带首轮也发 `If-Range`）⇒ 红在
`left: ["\"v1\"","\"v1\"","\"v1\"","\"v1\""]`。
三条 p3：
* p3-1 `Last-Modified` 支路端到端补上了：夹具新增 `last_modified` 字段 / `with_last_modified()`
/ 发出该响应头，`validator_ok` 扩展成「ETag 或 HTTP-date 比得上」（RFC 7233 的弱校验器兜底）。
新用例 `chunked/last_modified.rs`：服务器**只给** Last-Modified，重试必须带这个日期发
`If-Range`、只补 1 段（41984 = 1.025×）。变异（`record` 不写 last_modified）⇒ 红在
「只该在重试那一次发条件请求：[]」（变成 NoValidator 干净重下）。用例同时写明它抓不住真实
服务器的 HTTP-date 比较语义。
* p3-2 `ChunkJournal::save` 的同步原子写：判断「可以接受」并给了量级 —— 一个作业 ≤17 次
（16 段 + 建账）、每次 1–3 KiB，SSD ≈ ≤30 ms / 网络盘 ≈ ≤1 s，摊在分钟到小时的作业上占比
1e-4 量级；且顺序有意义（record-then-trust），挪 `spawn_blocking` 要为几毫秒引入跨 await
加锁的顺序风险；与单连接路径同口径。退路写在文档里。
* p3-3 `integrity=None` 时末尾摘要空转的一致性边界写进 `chunk_resume` 模块头「已知代价」+
`verify_part` 文档：只剩旧段自证与 `If-Range` 两道，「同长度换内容」不可察觉；现实入口是
上游没给合法 sha1 的 `ModFile`（`addon/online/download.rs` 只在 sha1 合法时才设 integrity），
以及 `Library` 元数据 / `download.bin` 缓存等无摘要调用点；要收紧属于产品决策。
字节判据复测（三条探针形态）：
healthy bytes=41984 size=40960 ratio=1.025 hits=5 resumed_from=30720
nofeature bytes=72704 size=40960 ratio=1.775 hits=8 resumed_from=0
staleval bytes=41984 size=40960 ratio=1.025 hits=5 resumed_from=30720 if_range=["\"v2\""]
即 stale-validator 那条从 2.775× 回到 1.025×，healthy 档未变差。
门禁：lib 903 / engine_mock 17 / chunked 22 / resume 12 / partfile 7 / cache 6 全绿；
clippy -D warnings 0、fmt --check 0。改动的单文件最大 391 行（chunked_test.rs），无超 400。
|
2026-11-13 06:59:58 +08:00 |
|
|
AskaEth
|
ffca0f4454
|
fix(download): 换源后不再沿用旧源校验器 + 三条 p3 收口（M293 r1）
复审 r1（p2-1）指出的链条：源 A 落 3/4 段失败 ⇒ 元数据 url=A + A 的 ETag；换源 B 时
`decide` 判 UrlChanged、删盘重来，但 `ChunkJournal::begin` 把 A 的校验器原样写进 url=B 的
新元数据，而 `record` 只在 `etag.is_none()` 时写入 ⇒ B 的真实校验器永远盖不上。于是拿 **A 的
ETag** 对 B 发 `If-Range`：按 RFC 7233 §3.2 服务器回 200 + 完整正文 ⇒ `fetch_chunk` 判
RangeUnsupported ⇒ 丢掉整份 ⇒ 单连接从头下 —— 债务以另一条路径复现。
修法（复审给的选项 A）：校验器与**记下它的 URL** 绑定，`same_source = previous.filter(|m|
m.url == candidate.url)`，`etag` / `last_modified` / `If-Range` 三处全部走它，让「谁能当校验器」
只有一个判定点。不选 B（换源时清空）是因为 B 只是 A 在「URL 变了」这一特例上的写法，条件放在
读取处比散到写入处更难漏；不选 C（多源各记一份）是因为 `ResumeMeta` 本来就有 url，再加一个来源
字段会多一处可与 url 漂移的状态。
夹具此前不解析 `If-Range`，这一跳只能读代码推。现在 `support/` 记录每个请求的 `If-Range` 取值，
并按 RFC 7233 §3.2 处置（对不上就忽略 Range、回 200 + 完整正文），于是「真实服务器上的后果」也
进了用例。
判据（新用例 `chunked/switch.rs`，两个夹具服务器当一个官方源 + 一个镜像源）：
* 源 B 收到的 `If-Range` 只许是它自己的 `"src-b"`（源 A 同源续传照旧带 `"src-a"` 作对照）；
* 源 B 的字节数仍是 3 段 + 卡住的 1KiB + 补 1 段 = 41984（1.025×），换源没把同源续传打回整份重下；
* 最终文件逐字节正确；
* 第二条用例走「新源自己不发 ETag」那一支：`NoValidator` ⇒ 新源重试整份重下（`resumed_from=0`、
8 个请求、72704 字节），一个条件请求都不许发 —— 这是「无法证明就不复用」的明确取舍。
变异（去掉 URL 过滤）⇒ 两条都红，实测原文：
assertion `left == right` failed: 源 B 收到了不属于它的校验器
left: ["\"src-a\""] right: ["\"src-b\""]
新源没有任何校验器，就不许发条件请求（带 A 的值更是串源）：["\"src-a\""]
同一变异下还实测到了后果：`b_bytes=113664 b_hits=6 resumed_from=0`（200 白下一份 + 单连接整份
重下 = 2.77×），即复审预测的那一跳确实存在。
三条 p3 一并收口：
* p3-1：`abort_all()` 之前用 `try_join_next` 把「已落完但还没被收走」的段记进账
（`absorb_completed`，总长判据与正常回收同一道）。这是尽力减少浪费、不是正确性前提，且
它是「谁先完成」的竞态 ⇒ 没有确定性用例能钉住，已在文档里写明边界。
* p3-2：`verify_chunks` 改为返回 `Option<u64>`（可复用字节数），`AttemptOk.resumed_from`
直接取它，删掉原来「记录另算一遍」的双份口径。
* p3-3：`chunk_resume` 模块头新增「已知代价」：重读量正比于**复用的字节**（不是整份文件）、
为什么不能用「相信摘要」来省掉、以及超时后 `spawn_blocking` 线程不可取消在 Windows 上的
句柄风险。
拆文件守 400 行硬线：`await_chunks` + `absorb_completed` 移到 `transfer_chunk/join.rs`
（逐字节搬移），`MockResponse` 移到 `support/response.rs`（逐字节搬移，只加 `with_etag` /
`without_etag` 两个构造器）。
门禁：lib 903 / engine_mock 17 / chunked 20 / resume 12 / partfile 7 / cache 6 全绿，
clippy -D warnings 0、fmt --check 0；字节判据复测未变差（resume 41984 = 1.025×，
noresume 72704 = 1.775×）。
|
2026-11-13 06:45:55 +08:00 |
|
|
AskaEth
|
3ade2d14a8
|
feat(download): 分块路径写续传元数据并自证旧字节（M293）
台账 P21 第 2 条 + P19(b)：分块路径此前进来先 `part.discard()`、失败也 `discard()`，
188MB 的 JDK 任何一次失败都从 0 重下；M289 又给预算耗尽加了「不再重试、不再换源」的
短路，慢链路上一次晚到的失败就变成「这个文件下不来」。
写这一侧：
* `ResumeMeta` 新增 `chunks: Option<Vec<ChunkRecord>>`（段区间 + 该段 SHA-1），
由新增的 `chunk_resume::ChunkJournal` 每成功回收一段就原子落一次盘；
* `fetch_chunk` 顺带带回段摘要、`Content-Range` 总长与 ETag/Last-Modified，
所以元数据里同时有 total / 源 URL / 分块清单 / 校验所需信息；
* 分块失败不再丢中间文件，只有 `RangeUnsupported`（单连接接不住这种形状）才丢。
判这一侧：
* `chunk_resume::decide`（纯函数）要求策略允许、URL / 总长 / 摘要 / 校验器全对得上，
且每条记录精确命中本次分块规划里的一段，否则从头再来；
* `chunk_resume::verify_records` 按记录重读旧段、重算摘要：任何一段对不上就整份丢掉
（元数据本身已不可信，同批其它记录也不再被信任）；
* 续传的段请求带 `If-Range`，让服务器回答「内容变了没有」；
* 整文件摘要照旧在末尾整份重算，覆盖新下 + 复用的全部字节。
单连接路径零改动：`resume::decide` 的判定一字未动，只新增
「元数据里带分块清单 ⇒ 强行判 Restart 交给分块路径」这一条，避免预分配全长文件被
单连接的 `Complete` 误判成「已下满」。
判据（都是「服务端实际吐了多少字节」，不是「最终 hash 对」）：
* 3/4 处失败后续传完成：41984 字节 / 40960 文件 = 1.025×（断言 < 1.5×）；
* 变异（关掉续传同样夹具）：72704 = 1.775×，`< 1.5×` 必红（已实测）；
* 变异（去掉旧段摘要自证）：坏段被复用 ⇒ 51200 ≠ 40960 必红（已实测）；
* 变异（去掉总长比较）：旧大小的段被复用 ⇒ 61440 ≠ 40960 必红（已实测）。
|
2026-11-13 06:26:18 +08:00 |
|
|
AskaEth
|
d6f862a43c
|
fix(download): 补齐 download_bytes 与等许可两处无界 await，预算耗尽不再重试（M289 r1）
r1 复审 p2-1：`stall.rs` 那句「全仓只有两处无界 await」是假话。真实清单五处，
M289 之前只修了两处；这次补齐：
* `bytes.rs::fetch_bytes` 的 `send()` 改走 `http::send_bounded`（与文件下载同一个构造点）；
整包 `response.bytes()` 换成 `bytes_stream` + `http::read_step` 的空闲判定，并边读边卡
`MAX_IN_MEMORY_BYTES`（`Content-Length` 可缺失/可撒谎）。生产调用点：版本清单、
版本 JSON、Modrinth 元数据。
* `engine::acquire` 的 `acquire_owned()` 加上界（`EngineConfig::permit_timeout`，默认
120min ≥ 单个作业总期限），到点报新阶段 `StallStage::AcquirePermit`（「等许可」），
不冒充「服务器不给数据」。这就是「卡死作业攥着许可把队列堵死」的连坐形态。
* `stall.rs` 模块头改成一张「哪些入口有界、谁托管给谁」的表，并写清五处 await 的真实清单。
r1 复审 p2-2：总期限用完是链路级判决，不再按满预算重试/换源：
* `DownloadError::job_budget_exhausted()` + `DownloadError::is_retryable()`（覆盖
`kind.is_retryable()`），引擎与 `download_bytes` 都改用它；
* 引擎在预算耗尽时直接结束候选循环，不再换源（同一份字节、同一条链路，换源只会再
烧满一整个预算）。188MB/20 KiB/s 的用户不再从「1.6 小时慢慢下完」变成「几小时反复重下」。
* `stall.rs` 写明「慢链路照样活」的前提 = **平均吞吐 ≥ 32 KiB/s**，以及它挡掉哪类链路；
`download.*` schema 接线留给另一个 mission（`setting/keys.rs` 不在 scope）。
顺带（复审 p3）：
* `transfer.rs` 的读空闲统一走 `EngineConfig::deadlines()`（不再各读字段）；
* `verify_part` 补一条代价说明：`spawn_blocking` 到点不可取消，可能让同名重建拿到
`Access is denied`（**该假设未验**，注释里已标）；
* `engine.rs` 因这轮新增又贴到 410 行 ⇒ `finish` / `materialize` / `millis` 逐字节搬到
`engine/finish.rs`（`engine::millis` 路径用 `pub(crate) use` 保持可用）。
新增用例（全离线、<2s）：`download_bytes` 静默服务端 / 正文中途卡住、等许可超时、
预算耗尽不重试（`max_attempts_per_source = 3` 下仍只发一轮）、预算耗尽不换源
（官方源 `hits == 0`）。
|
2026-11-12 23:24:19 +08:00 |
|
|
AskaEth
|
cc0def3415
|
feat(download): 给每条下载 await 上界并在超时时报出「卡在哪一段」（M289 / P19）
全仓下载路径此前只有两处无界 await（分块与单连接的 `send()`），reqwest 自己的
`timeout` 又是 `None`：服务器接了连接不回一个字节 ⇒ future 永不结束，
`ull java install` 那条 `silent()` 路径零事件零日志，用户只看到「卡住不动」。
上界选「单次请求 + 读空闲」，**不是**「整作业总预算」：
* `region.rs` 的 3s 是探测极小响应（整作业 = 一次 GET，两者同一件事）；
* `font.rs` 的 ATTEMPT/TOTAL 是几百 KB 的字体（整作业几秒就完）；
* 188MB 的 JDK 两者都不能照抄，所以分三段互不顶替的界，理由与取数**只写在**
`crates/core/src/download/stall.rs` 模块头一处（含「别改成 reqwest 的 timeout，
它覆盖整个响应体读取」）。
改动：
* 新增 `download::stall`：`StallStage`（连接 / 等响应头 / 等字节 / 等分块回收 / 校验）+
`StallReason`（期限用完 / 没有新字节）+ `StallReport`（阶段 + 已收 / 预期字节 +
无进展时长）+ `job_budget`（总期限按 32 KiB/s 平均吞吐反推）。
* `http::send_bounded` / `http::read_step`：两处 `send()` 与两处读循环的**唯一**构造点；
超时错误带阶段与三个数，`message` 里也抄一份（整体失败时 `suppressed` 只搬 message）。
* `transfer_chunk::await_chunks`：`JoinSet::join_next` 加总期限与无进度窗口，两者靠
`StallReason` 分开报；窗口内有新字节就续期（慢但有效不误杀）。
* `verify_part` 挪到 blocking 池并套上界：校验阶段卡住也报得出来（阶段=校验）。
* `engine.rs`：整体失败时把**最后一次**尝试的失速现场带上去，并写进用户可见的那行字。
* 配置：`response_timeout` 60s / `chunk_stall_timeout` 120s / `chunk_job_floor` 10min /
`verify_timeout` 120s（`EngineConfig`，未动设置 schema）。
测试（全离线、`127.0.0.1`、<2s）：夹具新增 `silent()` / `stalling_after` / `short_body` /
`oversize_body` / `dripping`；用例覆盖静默服务端、中途卡住、短包、超长包、慢但持续
（4 倍于上界也要成功）、超时后引擎仍能下载（RAII 许可自还，不写手动归还）、以及分块
作业的「无进度 vs 总期限」两条。
另：`config/tests.rs` 的一处表达式在去缩进后行宽变化，随本 commit 由 rustfmt 合成一行
（纯搬移 commit 提交时它仍是逐字节原文）。
|
2026-11-12 23:24:19 +08:00 |
|