6 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	d584a2c42e	feat(download): 把 download.proxy_mode / download.proxy_url 接进代理三态（M295） ... 台账 P26：两个键引擎侧零消费者——`http::build_client` 只设 UA / 连接超时 / 重定向 / 默认头， 从不 `.proxy()`。设置页画着三档 chip 与一个地址框，改它对任何一次下载都不生效（`system` 那一 档「碰巧能用」只是因为 reqwest 默认读环境变量，不是这段代码做的）。 - core::download::proxy（新）：`ProxySetting::from_raw` 是**唯一**翻译层，三档落到 client 上： `none` ⇒ `.no_proxy()`（真直连，连 `HTTP_PROXY` 也不读）/ `system` ⇒ 不调任何代理 API （跟随环境变量 = M295 之前的行为）/ `manual` ⇒ `.proxy(Proxy::all(url))`；未知值 ⇒ `none`。 - 两条决定写进模块头：`proxy_url` 在非 manual 档**忽略**（不校验、不进结构，值原样留在文件 里）；`manual` + 空地址 ⇒ `system`（设置页那行文案一直这么承诺）。 - 非法地址不穿透：`Proxy::all` 解析失败 ⇒ 有界错误（`InvalidRequest` + 带原串的文案），不 panic；`DownloadEngine::new` 回落**直连**重建（不用 `reqwest::Client::new()`——那会跟随环境 变量代理，回落就不确定），原因留在 `proxy_problem()`，CLI 的 `download::engine` 打一行 stderr；`config().proxy` 不撒谎（仍是用户写的 `manual`）。 - `EngineConfig.proxy` 默认 `System`（=「没读设置」的档：auth 登录 / JDK 下载页 / 地区探测都 直接用它，保持老行为），`DownloadTuning.proxy` 默认 `Direct`（与 schema 的 `none` 一致）。 - 两键进 `RawTuning`（与 `gh_proxy` 同形），presenter 的 `tuning_of` 与 CLI 的 `tuning` 各加 两行；两个宿主都是完整字段字面量 ⇒ 「忘了读」是编译错误。`summary()` 加 `代理=…` 一档。 - 判据是「请求真的经过代理」：新夹具 `FakeProxy`（本地 TcpListener）+ 目标 `.invalid`（解析不 了）⇒ 拿到正文只可能来自代理，且代理记到的请求行是**绝对 URI**。三条用例：manual 真走代理 / direct 无视环境变量而 system 跟随（同一份 `HTTP_PROXY`）/ 非法地址回落直连不 panic。 变异 M17-M22 记在 docs/download-settings.md §6。 - 行为变化（doc §5.2 写明）：`none` 从「碰巧跟随环境变量」变成真直连，靠 `HTTP_PROXY` 上网的 用户要选一次 `system`。发布版 GUI 的「下载 JDK」页仍不读这两个键（finding 已开）。 - 门禁：四 crate `check --all-targets` / 测试（3201 passed, 0 failed）/ `clippy -D warnings` / `fmt --check`；另跑了 `check --workspace --all-targets`。判据用 `$?` 与 `test result:` 行验。	2026-11-13 10:43:09 +08:00
AskaEth	bde6649aab	fix(download): text_bounded 不再信 Content-Length 预分配，补两道内存闸；api/version 第四处裸 send 也上界（M290 r1） ... 复审 r1（p2-1 / p3-1 / p3-2 / p3-5）返工，三处既有结论（send_bounded 逐字节未动、三个既有调用方 零改动、阶段只用两档）原样保留。 **p2-1 `http.rs::text_bounded` 的内存**（复审判据成立）：`Content-Length` 是「对面说了算」的数字， 拿它喂 `Vec::with_capacity` 等于让远端决定我们的内存，而分配失败是 abort、进不了 `Result`。 改成三道闸： 1. 头里声明 > `MAX_IN_MEMORY_BYTES`（64 MiB）⇒ 读完头立刻有界失败，**不预分配、不读正文**； 2. 容量只按真实到达增长（`Vec::new()`）； 3. 读循环逐块卡同一道上限（在累加前判，不会先撑过上限一块）。 两道闸的 `message` 分别说「声明的长度」与「内存上限」，`kind` 都是 `InvalidRequest` ⇒ 与超时 （`Timeout` + 阶段）可区分。 **p3-1 第四处裸 `send()`**：`game/java/api/version.rs::fetch_release_page` 原本 `client.get(url).send()` + `response.text()`、整文件 0 处 timeout（生产路径：`source::pinned` → `api::fetch_version`）。改走 `http::send_bounded` + `http::text_bounded`，界是参数（生产 `http::default_deadlines()`，用例压到 200ms）。 **p3-2 `download/stall.rs` 模块头**：把「`game/java/api.rs`、`game/java/net.rs`、`update/github.rs` 是裸 `send()`——未审」这句假事实换成实测清单（谁已收、谁可以留、为什么留：`auth/http.rs` 自带 `.timeout`、`preflight.rs` 由 `check_with_deadline` 套住、`region.rs` 自带 3s），并给 `http::text_bounded` 补一行「入口/上界/阶段」。 **p3-5 doc**：删掉「与 `Response::text()` 的唯一差别是 charset 解码」这条过度披露——本仓 reqwest 没开 `charset` feature，`text()` 本来就是 `from_utf8_lossy`，解码逐字节等价；改成真实差别 （读空闲 + 内存上限）。 离线用例（全在 `#[cfg(test)]`，夹具 `game::java::net::probe` 新增 `Mode::Declared{declared,sent}` 与 `Mode::Flood(n)`，外加共用的 `bounded()` 护栏助手）： * `api/version.rs::bounded_probes`：静默 ⇒ 阶段等响应头；正文停顿 ⇒ 阶段等字节； 声明 `Content-Length: 999999999999` 且不发正文 ⇒ <2s 返回 `InvalidRequest` 且文案含 「声明的长度」；不声明长度灌 65 MiB ⇒ 读循环在 64 MiB 处拒。 * `net.rs::tests` 的六条（4 条原有 + 2 条正常路径）改用同一个 `bounded()` 助手，断言一条未放宽。 变异实跑（贴红原文见 mission 报告）： 1. 退回 `Vec::with_capacity(declared)` 且删提前拒绝 ⇒ `memory allocation of 999999999999 bytes failed` + 进程 abort（0xc0000409），测试二进制消失——不是一条红； 2. 只删提前拒绝（预分配仍是 `Vec::new()`）⇒ 干净红：`left: Timeout / right: InvalidRequest`（0.21s）； 3. 删循环里的上限卡口 ⇒ 干净红：`expect_err` 拿到 `Ok("xxxx…")`（0.54s）； 4. `fetch_release_page` 退回裸 `send()` + `text()` ⇒ 两条 version 用例各在护栏 5s 处 panic（5.01s）。 门禁（真实退出码）：check=0 / lib=896 passed / game=120 passed / launch=91 passed / engine_mock=17 passed / clippy -D warnings=0 / fmt=0。行数：http 389、stall 378、api 389、 net 390、version 397、github 363（全 ≤400）。	2026-11-13 00:22:22 +08:00
AskaEth	ad99303a95	fix(java/update): 三处模块外的一锤子 GET 也上界，失败时报出卡在哪一段（M290） ... `download_bytes`（M289）修掉之后，core 里还剩三处裸 `send()`，都在「拿上游文本/JSON」的 路径上：`game/java/api.rs::fetch_latest`（Adoptium latest）、`game/java/net.rs::get_text` （四家发行版的一锤子 GET）、`update/github.rs::get_candidate_text`（更新清单）。上游接了连接 就装死时它们永不返回，与 M289 修掉的是同族形态。 改动（全部复用 M289 的构造点，没有第二套超时包装）： * `download/http.rs` 新增 `text_bounded`（正文按 `read_step` 的空闲判定读成 `String`，与 `bytes.rs` 的读循环同口径）与 `default_deadlines()`（取 `EngineConfig::default()` 的两段界， 不另抄秒数）；`send_bounded` 的签名逐字节未动，`transfer.rs`/`chunked.rs`/`bytes.rs` 三处 调用方零改动。 * 三处一律 `send_bounded`（等响应头）+ `text_bounded`（等字节）：失败时 `message` 里带 `StallReport` 的阶段（`await_headers` / `await_bytes`）与已收/预期/无进展三个数。 这三条路径只用到这两档：没有分块回收、也没有引擎许可等待，所以 `await_chunk_join` / `acquire_permit` 不适用。 * `update/github.rs` 的界取 `engine.config().deadlines()`（手里有引擎就不抄默认值）。 正常路径零改变：`fetch_latest` / `get_text` 的公开签名与错误分类一字未动（`fetch_latest` 的 404 文案与 hint 保留），`update` 的 `github_cases` 全部断言未改。 离线用例（`game::java::net::tests`，6 条；夹具 `net::probe::Hanging` 也是 M290 新增）： silent 服务端 ⇒ 引擎自己在 200ms 上界内返回（外层 5s 护栏没触发），并断言 message 含 「等响应头/await_headers」；正文停住 ⇒ 「等字节/await_bytes」；200 + 真 JSON ⇒ 正文逐字节 原样（含中文）。变异已实跑：`send_bounded` 退回裸 `send()` 三处各自在外层 5s 处挂断； `text_bounded` 退回 `response.text()` ⇒ 等字节用例 5s 挂断；正文改成空串 ⇒ 正常路径用例红。 门禁：cargo check（core+cli, --all-targets）/ test --lib（892 passed）/ --test game（120）/ --test launch（91）/ --test engine_mock（17）/ clippy -D warnings / fmt --check，退出码全 0。	2026-11-13 00:22:21 +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
AskaEth	e3ae71ac37	M207: UA 收成一份带联系方式 + 两处字符串副本（gh_proxy 键、用例注释） ... 1) UA 只有一份定义：core 的 `download::http::USER_AGENT` （`Unlucky-Launcher/<CARGO_PKG_VERSION> (+仓库 URL)`，不用邮箱）。 - 引擎侧：`EngineConfig::default().user_agent` 直接取它（config.rs 等量替换，仍是 400 行） - 带 header 侧：presenter 不再持有 UA 字面量，`get_with_headers` 发 `engine.config().user_agent` M205 复审核实过的缺口：Modrinth 收到的是引擎那份 `UnluckyLauncher/<ver>`（无连字符、无联系方式）， 带联系方式的那份只发给 CurseForge 搜索 —— Modrinth 的 UA 政策在真正会被限流的路径上没被满足。 断言：core 一条钉形状（版本 == CARGO_PKG_VERSION、联系方式段 == 仓库 URL、不含 `@`）； presenter 一条在回环上抓**发出去的字节**（两条路径的 UA 逐字节相同且 == EngineConfig::default()）。 2) `app-iced/.../java/downloads/engine.rs`：`"download.gh_proxy"` 字面量改成 `KEY_GH_PROXY`。 3) `presenter/src/host/addon/http.rs` 的用例注释改成事实（Modrinth 走 core 的 EngineTransport， `get` 的无 header 分支生产零调用者），模块说明表格同步。 4) `docs/download-settings.md`：§6.1 / §6.1.1 / §7 按 M201（iced 真控件 + 快照通路）之后的现状重写。	2026-11-09 13:13:20 +08:00
AskaEth	bc41dfcf7d	Unlucky Launcher v0.0.1-alpha ... Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。	2026-10-31 21:54:10 +08:00