AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
829 Commits 3 Branches 7 Tags
c731d3fa541628906fcd5a746ad7f028869b2636
Commit Graph
7 Commits
Author SHA1 Message Date
worker-mirrorwire 69e3e198bf fix(download): M294 r1 —— JDK 下载页与 CLI 也接上源选择，文档同步 
复审 p1：发布版 GUI 的「下载 JDK」页是第二处 DownloadEngine::new（要 with_progress
拿走引擎），此前只读了 gh_proxy，region / mirror_preference 到不了那里；报告却把 GUI
写成「已接」。复审 p2：CLI 四条命令同样不认这两个键 —— 同一份 launcher.json 在 GUI 与
CLI 上表现不同，等于把「设置项说假话」挪到 CLI 侧。

- app-iced downloads/engine.rs：新增 SourceSelection（只读键、不翻译）+
  engine_with(.., &SourceSelection)，在 gh-proxy 三态之前叠
  DownloadTuning::with_source_selection(..).apply_source_selection(..)
- Request 加 source_selection 字段，构造点（app/update/settings/java/downloads.rs）
  用 SourceSelection::of_config(&config) 显式传值（不从缓存根反推配置路径：
  反推失败会静默按 auto 收场，正是本 mission 要消灭的形状）
- cli download.rs 的 tuning()：链 .with_source_selection(..)，四条命令共用这一处装配
- core 的 summary()：把「地区 / 镜像偏好」两档印进 CLI 那行生效值（CLI 既然读了，
  少印两项就是新的半真话）
- shared.rs 注释说清「共享引擎」与本文件的第二处装配点；app-iced 模块头补对照表
- 新判据：JDK 下载页与 CLI 各一条断候选源顺序的用例，均配变异验证（换回裸
  EngineConfig::default() / 裸 tuning 即红）；补一条 region=cn + gh_proxy=off 的
  叠加次序守卫（复审 P3-2）
- docs/download-settings.md：§1 表格两行、§5 拆「已接 / 未接」、新增 §3.1.1 覆盖面
  表、§6 补 M14-M16 三条变异、§7 补「镜像可达性没验」

连带（不加就编不过，已报备 tower）：downloads/tests.rs 的 Request 字面量 +1 行、
downloads/tests/gh_proxy.rs 两处 engine_with 调用点补第四参。
 2026-11-13 09:00:00 +08:00
worker-mirrorwire 0f64acbd05 feat(download): 把 download.region / download.mirror_preference 接进源选择（M294） 
两个键此前在引擎侧零消费者：设置页画着三档 chip，改它不影响任何一次下载。
现在它们是 RegionProfile 之上的一层显式覆盖（读时叠加，不落盘，region.json
仍是自动判定的结论）：

  显式 mirror_preference（official/mirror）
    > 显式 region（cn/global）
      > 自动探测（时区+语言+系统信号）与 24h 缓存

- core::download::preference（新）：两个枚举的 from_raw（未知值/空串 ⇒ auto）
  与 apply；两个键都落到 RegionMode 这一个「谁在前」开关上，不造第二套排序
- region::RegionProfile::overridden：在已有判定上叠一层模式（探测逻辑不动）
- DownloadTuning 加 region / mirror_preference 与 apply_source_selection
  （组合顺序 = 优先级），shared::build 改用它；默认 Auto ⇒ 逐值等于今天
- 未进 RawTuning：CLI 的 tuning() 用完整字段字面量构造它，加字段会连累
  crates/cli（不在本 mission scope），改走 with_source_selection 入口
- presenter 的 tuning_of 读这两个键（否则 GUI 侧仍是假行）

判据断具体源名序列：不设/auto/未知 ⇒ ["bmclapi","official"] /
["official","bmclapi"] 逐项不变；official/mirror/cn/global ⇒ 顺序跟着换；
另有一条从设置原文到引擎 plan() 的端到端用例。
 2026-11-13 08:26:30 +08:00
AskaEth b31ca636d1 feat(m203): CLI 三条下载命令改吃 download.* 设置（并发/重试/gh-proxy） 
`ull install` / `ull java` / `ull pack` 此前各自 `DownloadEngine::new(EngineConfig::default(), …)`：
用户在设置里配的 `download.concurrency` / `retry_limit` / `gh_proxy` 一概不生效；M193 把出厂并发
从 64 改成 8 之后，它们还静默跟着降了。现在三处都经 `crates/cli/src/download.rs::engine(ctx)`：

- core：`shared/tuned.rs` 新增 `engine_with_tuning(cache_root, tune)` = `set_tuning` + `engine_for`，
  由 `shared.rs` 重导出；`engine_for` 的签名与行为一字未改（presenter 的两步语义原样保留）。
  放子模块是为了不动 `engine.rs`（那是 400 行零余量），`shared.rs` 仍 398 行。
- CLI：`download::tuning(ctx)` 用 `SettingStore::load(ctx.launcher_config(), launcher_schema())` 读
  三个键（与 `ull config set` 同一份文件），默认值/夹取/回落在 `DownloadTuning::from_settings`；
  键缺失或坏值静默回落出厂值，`engine()` 没有错误通道，安装不会因此中断。
- 顺带：`ull update` 复用 `install::build_engine`，也随之吃到设置。
- 测试：`crates/cli/src/download/tests.rs` 三条命令各一条（读 `config().max_concurrency` 与
  `concurrency_probe()` 的真实值）+ 一条「缺失/越界/负数/类型不对 ⇒ 静默回落出厂值」；
  `shared/tuned.rs` 两条守住「灌调优与取引擎是一步」。变异实测：pack 换回裸 `EngineConfig::default()`
  ⇒ 只有 pack 那条红（left 8 / right 2）。
 2026-11-09 10:07:41 +08:00
worker-dlmsettings 94f56f9d9c fix(m193): 复审 r1 三条 P2——版本史还原、retry_limit 0 有诚实语义、装配点措辞更正 
- P2-2：keys.rs 的 schema 版本史按原文逐字还原（1.4.0/1.5.0 的键名、1.2.0 的迁移口径、
  旧读新的完整结论），不再用版本文档换行数；腾行改从我自己新加的注释里出。
- P2-1：download.retry_limit 范围恢复 0~10，并把 0 的语义定成「只试一次」（attempts = max(1, 0)）：
  老配置合法、零迁移、ull config get 读到的 0 与引擎真做的事一致（不再回落出厂 3）。
  schema 描述与 presenter/iced 两处 UI 都写清「0 与 1 都 = 只试一次，不代表不下载」。
- P2-3：shared.rs 的「唯一一处装配」更正为「presenter 侧唯一一处」（CLI 还有三处自建），
  docs 加「哪些路径吃这套设置」表，并立 finding（CLI install/java/pack 不读设置、并发 64→8）。
- P3-3：mirrors.rs 的 gh_proxies 注释改成「无生产读者，仅解析留档」。
- P3-4（presenter 侧）：并发/重试描述的出厂值与上限改用常量 format!，不再是第二处字面量。
- 出图重拍（含 0/1 = 只试一次）。
 2026-11-09 05:24:12 +08:00
worker-dlmsettings e8544b19a7 feat(m193): 下载并发/重试/gh-proxy 真接进引擎（schema 与引擎同源常量） 
- download.concurrency / download.retry_limit 以前引擎侧零消费者（恒用
  EngineConfig::default() 的 64，而 schema 说 8）。现在默认值与硬上限收成
  download/config.rs 的常量，schema、EngineConfig::default()、Semaphore 容量
  三处同源；宿主把三个键翻译成 DownloadTuning 后经 shared::set_tuning（按数据根）
  灌进装配点，改了设置下一次取引擎就生效。
- download.gh_proxy 三态（留空=跟随内置默认 / off=关 / 前缀=覆盖）下沉到
  shared::build，所有走共享引擎的下载路径（内容库/版本清单/字体/安装）一致。
- 删掉 MirrorTable::set_gh_proxy 与 default_gh_proxy 两个改了没用的入口。
- 下载设置页把三条假演示值换成说语义的中文行（含三态说明与 1~64 硬上限）。
- 守卫：探针读 Semaphore 真实许可数（不是读配置），每条配变异证明。
- docs/download-settings.md 记下取证表（另四个键仍零消费，已立 finding）。
 2026-11-09 05:24:11 +08:00
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 干净。真站点仍未打（见报告「没验的部分」）。
 2026-11-08 09:30:05 +08:00
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）未打，见报告。
 2026-11-08 09:30:05 +08:00