011d525e8de07d4a12bbcea361c6d44851bc52ee
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 AskaEth
|
460da9330d |
fix(m168): 复审 r3 四项 —— 说准 panic 档、给两条修复补守卫、时限算术补洞
复审 r3（p2-4items / fix-then-merge）四项 + 顺手五条：
1. **P2-1 `catch_unwind` 在发布档是死代码，三处文档说了不成立的话**：
`Cargo.toml` 的 `[profile.release]` 是 `panic = "abort"`（只有 `fast` 是 `unwind`），发布走
`--release`。分两半写清楚：①**闸前移仍安全**——release 档 panic 是进程退出，不存在永久停在
`Downloading`；`dev`/`test`/`fast` 档 `catch_unwind` 真会写 `Failed`；②但「下载失败不崩」在
panic 这一支上对发布版**是反的**：注册/`load_font` panic ⇒ 启动器整体 abort，不是降级。
`install.rs::plan_with_offline` 的文档（新增两档对照表）、`worker.rs` 模块文档与 `run` 注释全部
按这个说法重写，不再用 `catch_unwind` 给「不崩」背书。
2. **P2-2 「启动不发起下载」这条修复没有守卫**：拆出纯函数
`fonts::resolve_with_faces(setting, faces)`（`resolve_with` 只是 `system_faces()` 的包装），
新增 `fonts::tests::resolving_fonts_never_starts_a_download`：给一张只有拉丁族的脸表
（一定判 `NeedsDownload`），断言调用后 `install::status()` **不是** `Downloading`。
变异（实跑）：把 `install::after_probe(cjk_report.strategy)` 加回 `resolve_with_faces` ⇒
`求值字体**不许**发起下载（状态从 Unknown 变成了 Downloading { bytes: 17772300 }）`，红。
3. **P2-3 时限算术有洞 + `is_last` 没守卫**：改 `ATTEMPT_DEADLINE=60 s` / `TOTAL_DEADLINE=420 s`
（原来 120/360 时，第一个候选吃掉 120 s 后最后一个只剩 240 s ⇒ 门槛 72.3 KiB/s，r1 实测
67 KiB/s 需要 259 s，仍然必失败）。文档按新数值重算成一张表：第一个候选瞬间失败 ⇒ 420 s ⇒
42.3 KiB/s；爬满 60 s 被切 ⇒ 360 s ⇒ 49.4 KiB/s，两者都低于实测最慢的 67 KiB/s。
守卫：把同解的旧用例换成 **单候选 + attempt 300 ms / total 5 s**——有 `is_last` 时跑到总时限
（≈5 s），没有时 300 ms 就切，两种实现可分辨。变异（实跑）：删掉 `is_last` ⇒
`the_last_candidate_gets_the_whole_remaining_budget` 红在
`最后一个候选该拿整个剩余预算（≈5 s）…452.6035ms`。
4. **P2-4(b)(c)**：①`install::tests` 里三处判据用例改用 `plan_with_offline(..., false)`，把进程级
`OFFLINE` 从判据里摘出去（否则同进程里 `headless(screenshot_options())` 会把它置 true 且从不
还原 ⇒ 结果依赖执行顺序）；②`fonts.rs` 注释改成真实机制——出图 harness 不经
`App::with_presenter`、压根没有 `set_offline`，它零流量靠的是「`resolve_with` 不触发」。
顺手：①`sha256_mismatch…` 的 doc 改成「两层校验互备，本用例抓的是两层同时拆」（原来说
「拆任意一层就红」是假的）；②`font.rs` 文档「把 90 s 压成 300 ms」→ 60 s/420 s；③`install.rs` 与
`catalog/font_install.rs` 的「≈17 MB」→ 16.9；④`worker::start` 的裸 `thread::spawn` 换成
`Builder::spawn`，起不来就落 `Failed`（发布档 panic = abort，不能让它 panic）；线程体抽成 `run()`。
验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，取退出码、不截断）：
- `cargo test -p unlucky-app-iced --lib` → **688 passed / 0 failed / 2 ignored / exit 0**
- `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0**
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0
- `cargo fmt --all -- --check` 干净；全仓无文件 >400；本轮改动文件最大 378（`app-iced/src/fonts.rs`）
|
||
|
AskaEth
|
b9009c0e61 |
fix(m168): 复审 r2 三项 —— 夹具不再空转、启动不再替英文用户下载、时限不再判慢线下不完
复审 r2（p2-3 / fix-then-merge）三项：
1. **P2-1 爬行服务端是空转的**（`font/tests/support.rs`，从 `tests.rs` 拆出守 400 行）：
`seen.windows(4).any(|w| w == b"\n\n")` 拿 4 字节窗口比 2 字节切片 ⇒ `PartialEq` 先比长度 ⇒
恒 false ⇒ 请求头永远读不完、一个字节不发，用例证明的其实只是「连接挂着被掐断」。上一版
这里是 Python 生成时把 `\r\n` 落成了真实换行字节。现在两处都是转义写法
（`b"\r\n\r\n"` + 完整 CRLF 响应头），并且**把「夹具真的在说话」变成断言**：
`serve_trickle()` 返回 `TrickleProof { header, dripped }`，用例断言「真的发过头」「真的挤过
字节」——否则夹具再坏一次也会绿。拆成两条用例：`a_trickling_candidate_is_cut_by_the_attempt_deadline`
（[爬行, 正常]，300 ms 切断第一个后第二个成功，0.38 s）与
`the_total_deadline_cuts_a_single_crawling_candidate`（单候选 + 400 ms 总预算）。
变异证明：把服务端改成「一个字节都不发」⇒ 两条用例红在「爬行服务端必须真的发出响应头」。
2. **P2-2 启动替英文用户下 17 MiB（真行为 bug）**：
- `fonts::resolve_with` **不再触发下载**（启动那一拍只报告判据）。唯一的触发点收在
`fonts::cjk_for`（`ui/lang.rs::log_cjk`），那一拍的 `setting` 与 `LangChoice` 同源
（ULL_LANG > 配置 > 系统 locale）= 「界面实际用哪种语言」。
- `plan` 把 `is_downloading()` / `Ready` 的闸提到**所有策略之前**：上一版只在 `NeedsDownload`
分支里，"下载中 + Unprobeable" 会把状态改回「无法探测」而线程还在飞，下完又翻回「已就绪」。
当时那条理由（「否则界面停在正在下载」）只对僵死成立 ⇒ worker 现在用 `catch_unwind`
兜底「任何 panic 都写终态」，闸才敢前移。
- 出图通道：新增 `install::set_offline(true)`（`App::with_presenter` 在
`options.screenshot.is_some()` 时调），`plan_with_offline` 在 offline 下永不 `Start`。
于是 `pages/harness/app.rs` 与 `--screenshot` 都不会在 zh-locale 无字体机器上真下 17 MiB。
- 被钉住的旧判据（`Unprobeable + Downloading ⇒ Apply`）改成 `Skip` 并写明旧行为为什么是错的；
新增 `every_strategy_skips_while_a_download_is_in_flight`（四策略打表）与
`the_screenshot_channel_never_starts_a_download`。
3. **P2-3 90 s 单次上限把「慢但能下完」变永久失败**：改 `ATTEMPT_DEADLINE=120 s` /
`TOTAL_DEADLINE=360 s`，并且**最后一个候选拿整个剩余总预算**（前 n-1 个仍 `min(单次, 剩余)`）。
算账写在常量文档里：17 772 300 B / 360 s ≈ 49 KB/s，比 r1 实测最慢那条 IPv6（67~77 KB/s）
还低一档 ⇒ 慢而能下完的线路仍有一次成功机会；健康线路（1.1~16.6 s）在第一/第二个候选就结束。
代价（最坏 6 分钟）也是刻意取舍，写在同一处。
顺手：`i18n::CjkFont::source` 的「尚未钉死」改成指向 `Source::Pinned`；`clock.rs` 与
`general_section.rs` 注释里的 17.0 MB → 16.9 MB。
验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，全量重编；取退出码，不截断）：
- `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0**
（lib 625 + setting 115 + 其余 14 个）
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0
- `cargo test -p unlucky-app-iced`（含 `no_hardcoded_tokens` integration）→ **693 passed / 0 failed / exit 0**
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0
- `cargo fmt --all -- --check` 干净；全仓受检文件 ≤400（本分支最大 361）
|
||
|
AskaEth
|
875b792206 |
fix(m168): 复审 r1 五项 —— 修红的 integration target、独立失败域、整体时限
复审 r1（p1-1/fix-then-merge）五项全改：
1. **p1-1 CI 会红的 4 条 integration test**（`crates/core/tests/setting/`，我上一轮只跑了 `--lib`，
scope 漏掉了覆盖 schema 版本号的目录式 target）：
- `java_install_keys` / `isolation_keys` / `appearance_keys`：版本断言 1.6.0 → 1.7.0（M168 的
`ui.font_cdn`），并写明「每加一批键推一次 minor 是纪律」。
- `update_keys::a_read_only_launcher_config_never_retires_the_legacy_file`：夹具从**写死
1.7.0** 改成 `launcher_version().minor + 1` 经 `SchemaRef::url()` 生成。写死数字的版本一推
这条守卫就变成「同版本」⇒ 文件可写 ⇒ 迁移真的执行 ⇒ 旧文件被退役，而断言还绿着（用户数据
守卫静默失效）。相对推导不会过期。
2. **p2-1 备用镜像不备用**：`cdn` 与 `fastly` 同属 Fastly（都 CNAME 到 jsdelivr.map.fastly.net），
换掉。现在首选 `gcore.jsdelivr.net`（Cloudflare，独立失败域），二选 `cdn.jsdelivr.net`
（Fastly）。注释里放了实测表（本机 + 复审机两份数据、字节数、sha256、IPv6 慢路径），
并写清排序依据（Fastly 侧 IPv6 实测 67 KB/s ⇒ 丢掉 4 分钟；Cloudflare 侧两次都完整下完）。
3. **p2-2 整体时限**：`core::download::font` 新增 `ATTEMPT_DEADLINE = 90 s` /
`TOTAL_DEADLINE = 180 s`，落在本模块自己的候选循环里（不动引擎全体语义）：每次尝试
`min(单次上限, 剩余总预算)`，超时归 `Network` 档。新增守卫
`a_trickling_connection_is_cut_by_the_deadline`（回环服务端每 100 ms 挤 1 字节、预算 300 ms）。
顺带修掉一个真 bug：`tokio::time::timeout` 在运行时外构造会 panic（5 条既有用例当场抓到），
现在整段包进 `block_on(async { … })`。UI 文案改成「网络不通或太慢（超时）」，不校验失败混。
4. **p2-3 说 `Source::PendingPin` 的两处**：`fonts/cjk.rs` 的模块文档已改；`ui/lang.rs::log_cjk`
那句「D28 的下载通道还是 PendingPin」（在下载已发起之后打印，等于当面否定本功能）改成
「已按 D28 发起下载，见 [font] cjk-download … 与设置页那一行」。全仓再扫，只剩注释里的历史说明。
5. **p2-4 假守卫**：判据抽成纯函数 `install::plan(strategy, current) -> Step`（`Skip` / `Apply` /
`Start`），`after_probe` 只执行。旧的空转用例换成打真判据的打表用例；变异证明：删掉
`Skip` 那一臂 ⇒ `a_started_or_finished_install_is_not_restarted` 红（已实跑）。
次要项也一并处理：`from_cache` 改成**本次是否真的命中缓存**（`CdnFetcher::was_cached()`，
`has_cached()` 降级为诊断字段 `cache_present=`）；`FontSpec` 的 URL 口径收紧为「非回环必须
https」（`is_acceptable_url` + 守卫）；`ui.font_cdn` 写进状态行 hint；文档里的 17.0 MB → 16.9 MB。
`download/font.rs` 拆出 `font/spec.rs` 守 400 行。
验证（这台机器上单个 800 MB 测试 exe 链接要 10 分钟，链接期间文件被 Defender 扫描，故耗时很长）：
- `cargo test -p unlucky-core --all-targets` → **1188 passed / 0 failed**（16 个 target，含
`setting` 那个 115 条、上一轮红 4 条的 integration target）
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed
- `cargo test -p unlucky-app-iced --lib` → 685 passed / 0 failed
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → 干净
- `cargo fmt --all -- --check` → 干净；全仓受检文件行数最大 388（<400）
|
||
|
AskaEth
|
449ded2cb7 |
feat(m168): 中文字体 CDN 下载真接线（D28 后半）
M167 调研的结论是「中文字体 CDN 下载至今未实装」：`i18n::font` 只有 `Fetcher` trait 与
假实现，`needs-download` 分支什么也不做。这条把它接成一条真链路。
判据 → 下载 → 注册（一条链，四个 crate 各管一段）：
* `unlucky_i18n::font`（零依赖）：`Source::Pinned { urls, sha256, bytes }` 把「下什么」
钉死——google/fonts 的 `NotoSansSC[wght].ttf` 钉到 commit `2894aab…`（不是 `@main`），
17 772 300 B / sha256 `a3041811…`。可变字体一份覆盖 wght 100–900，省掉三份静态子集的 25 MiB。
`FetchError` 补第三档 `Disk`（网络 / 校验 / 磁盘，UI 按类别选词）。
* `unlucky_core::download::font`（新）：缓存命中 → 共享引擎 `download_bytes` → 复验（sha256 +
sfnt 魔数 + 32 MiB 上限）→ 原子落盘。**复验在写盘之前**，所以「哈希不符」时盘上什么都没有；
缓存按 `<sha256 前 16 位>` 命名，pin 一换自动换名。
* `unlucky_app_iced::fonts::{cdn,install}`（新）：`CdnFetcher` 把 pin 接进 core（`ui.font_cdn`
可覆盖 URL，哈希不换）；`install` 是状态机 + 后台线程，只有 `NeedsDownload` 才起线程
（英文 / 系统已有 / 探测不出一律零网络）。注册走 `iced_graphics::text::FontSystem::load_font`，
族名从字体库读回来核对。失败只降级（继续用系统字体），不阻塞、不崩。
* 接入两条路径：`fonts::resolve_with`（启动）与 `fonts::cjk_for`（设置页切语言）都调
`install::after_probe`；设置页 General 组多一行状态（下载中 / 完成 / 失败 / 无需下载 + 三类失败
原因），文案进 catalog 金表（链尾追加，既有顺序不动）；`App::advance` 每秒比对状态快照后重建
视图模型，所以那一行会自己刷新。
配置：新增 `ui.font_cdn`（`keys/font.rs`，schema 1.7.0），空 = 内置 jsDelivr 镜像（含备用边缘）。
守卫（三条都能变红，变异证明见报告）：core 侧 8 条（缓存不联网 / 哈希不符拒落盘 / HTML 不当字体
/ 坏缓存自愈 / 上限 / pin 校验），app 侧 6 条（三种闲置策略零调用、失败不注册、类别不串、幂等、
截图钉子、单行日志），页面侧 1 条（四态 × 两语言无缺译、不写假百分比）。
测试：`cargo test -p unlucky-i18n --lib` 31 绿；`-p unlucky-core --lib` 622 绿；
`-p unlucky-app-iced --lib` 684 绿；`cargo fmt --check` 干净。截图三张见报告。
|
||
|
AskaEth
|
afe169751f |
fix(m165): forget 之后让自更新也换引擎（复审 P2-1）+ 卡口计数与端到端守卫
复审 P2-1（采「修法 1」，不是只改措辞）：`shared::forget` 只让登记处不再持有 那一份，换不掉自更新 `Factory` 里常驻的 Arc —— 于是「重新检测地区」对更新路径 不生效，直到重启。现在设置动作会把 Factory 一起重建。 - presenter/update_state: `Runtime::rebuild_factory` + `CoreHost::refresh_update_factory`； 只换 factory，不动 view/inflight（在飞的 Job 派发时已克隆走装配，重建不打断它） - presenter/dispatch: `SetSetting` 成功且键是「重新检测地区」时调 refresh - presenter/engine: `DETECT_REGION_ACTION` 常量（设置页行 id / set 分派 / dispatch 判断共用）；放这里而不是 settings.rs 是因为后者已到 400 行红线 - core/shared: 文档改准 —— forget 的范围是「登记处不再持有」，长命持有者必须自己重建； 记账从 `engine_for` 移到 `DownloadEngine::new` 这个卡口（分两把锁，避免自锁）， 于是 `constructions` 连绕过登记处另造引擎的调用点也统得住 守卫（都做了变异实证）： - update_tests::detect_region_rebuilds_the_update_factory_engine：走真实命令路径 `AppCommand::SetSetting` → 断言 Factory 换了引擎且指向登记处当前实例；变异（删掉 dispatch 里那句 refresh）→ 红在 Arc::ptr_eq - update_tests::rebuilding_the_factory_does_not_touch_a_running_job：重建不清 inflight、不改快照，在飞 Job 仍能跑完 - addon/http::tests::three_host_request_paths_share_one_engine：连走三条真实宿主路径 （Modrinth 元数据 GET / CF 带 header GET / Java 页渲染）后 constructions == 1； 变异（让 get_via_engine 自己造引擎）→ 红，left:2 right:1 顺带修：settings.rs 在上一提交被推到 403 行、engine.rs 401 行，两者都超 guards.yml 的 file-size 红线（>400 直接失败）。现在 settings.rs 400 / engine.rs 399， 全仓 `*.rs` 复跑「>400」扫描无输出。 验证：core lib 608 过、5 个 download 集成 target 42 过、presenter lib 270 过、 clippy --all-targets 干净、fmt 干净。真站点仍未打（见报告「没验的部分」）。 |
||
|
AskaEth
|
46389d61fd |
feat(m165): 下载引擎按数据根跨请求复用（运行时常驻 + 构造次数守卫）
宿主侧以前每次请求都现建一个 DownloadEngine：连接池、信号量限流、 健康度记忆、内容寻址缓存索引全部清零。现在改成按数据根共享一个实例。 - core: 新增 download::shared（进程级登记处，键 = 缓存根）—— engine_for / forget / constructions；region/health/cache/mirrors 的装配 收在这一个 build() 里（持锁构造只做本地 I/O，不联网） - core: download::blocking 改成进程内唯一常驻运行时。reqwest 的连接池绑在 驱动连接的运行时上，引擎复用必须配运行时常驻，否则复用的是个装满死连接的池 - presenter: host::engine::engine 返回 Arc<DownloadEngine>（共享实例）， addon/update/versions/java/authlib 等全部调用点随之改；新增 forget 供 「重新检测地区」失效（否则进程级引擎下那句话不成立） - presenter: addon 详情页把「项目 + 版本列表」两次 block_on 收成一次 失败分类 / 镜像回退 / Retry-After 语义未改动（error.rs、http.rs、engine.rs 的 候选循环一字未动）。 守卫（都带变异实证）： - shared::tests::one_engine_per_cache_root + host::engine::tests:: host_requests_share_one_engine：断言 constructions(root) == 1（不是只看结果） - shared::tests::pooled_connection_survives_across_block_on_calls：127.0.0.1 回环服务统计 accept 次数，两次 block_on 必须只拨号一次 验证：cargo test -p unlucky-core --lib（608 过）、5 个 download 集成 target（42 过）、 cargo test -p unlucky-presenter --lib（267 过）、cargo clippy --all-targets、 cargo fmt --check 全绿。真站点（Modrinth/CurseForge/BMCLAPI）未打，见报告。 |
||
|
AskaEth
|
b394316df4 |
fix(m162-r1): 叶子成因穿出引擎 + 安装路径切 core 在线源 + 详情迟到结果闸门
P1-1（p1-1items 的根因）： - download/error.rs：`DownloadError` 增 `leaf: Option<DownloadErrorKind>` 与 `effective_kind()`；`leaf_of()` 汇总规则只此一处：全 404 ⇒ NotFound、有 Network/Timeout ⇒ Network、全 5xx ⇒ ServerError、混合按「网络错 > 5xx > 404」 取最可诊断的那个（**不从 suppressed 文本猜状态码**）。 - download/bytes.rs：候选源循环收集逐源 kind，收尾时把叶子挂到 AllSourcesFailed 上。 - online/transport.rs：`From<DownloadError>` 改用 `effective_kind()`，于是 NotFound/Server/Integrity 在生产路径可达（项目被删/id 拼错/限速不再画成「未联网」）。 - import/fetch.rs：新增 `FetchErrorKind::Offline`（真正的「没联网」）并与 Network 分开； `From<DownloadError>`/`From<OnlineError>` 都按叶子/大类映射。 - import/complete.rs：补全只在 `Offline` 时早停；404（真实 mrpack 大多托管在 CF CDN， Modrinth 必然 404）与 5xx 只影响那一条，不再掐掉整轮；注记「因未联网提前停止」因此 只会在真断网时出现。 P2-1：presenter 安装路径不再自己拼 Modrinth URL / 自己解析 JSON——改用 `core::addon::online::Modrinth::versions` + `primary_file()` + `VersionFile::sha1/sha512`； `HostTask::InstallDone.result` 改成 `Result<String, ContentFailure>`， `InstallProgressView` 增 `failure_kind`（离线 ≠ 查无此项）。 P2-2：`app/update/content.rs` 把被详情方法抢走的「装入闸门」注释还回 `content_install_request`，详情方法只留自己那一行。 P2-3：`ContentState::apply_detail/fail_detail` 带上 project（事件与 HostTask 都携带请求时的 项目 id），迟到结果一律丢弃；`request_detail` 记下在飞项目，`detail_pending` 不再被迟到 结果清掉。 顺手项：`usable_hash` 让形状非法的那一档摘要被**丢弃**（sha512 仍校验，不再整条跳过； 两档都不可用才拒绝）；`digest_file` 的 IO 失败先删落盘文件再返回。i18n 的 ContentOfflineBody 改成不暗示「有缓存」的措辞（golden 同步）。 用例：download/error.rs 叶子四档 + effective_kind；online/tests/classify.rs 5 条 （AllSourcesFailed+leaf 404 ⇒ NotFound、无叶子 ⇒ NotConnected 保守、叶子一一映射、 单源自身 kind、导入侧 404≠Offline）；import_online 增「404 不停」「真离线才停」 （共 7 条）；download 增「sha1 形状非法仍用 sha512 校验成功」；presenter 增详情迟到闸门。 |
||
|
AskaEth
|
bc41dfcf7d |
Unlucky Launcher v0.0.1-alpha
CI / fmt (rustfmt --check) (push) Canceled after 0s
CI / clippy (ubuntu-latest) (push) Canceled after 0s
CI / clippy (windows-latest) (push) Canceled after 0s
CI / test (ubuntu-latest) (push) Canceled after 0s
CI / test (windows-latest) (push) Canceled after 0s
CI / build release (ubuntu-latest) (push) Canceled after 0s
CI / build release (windows-latest) (push) Canceled after 0s
Guards / core 零 UI 守门 (push) Canceled after 0s
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。 |