AskaEth
f6cdbff885
test(download): 补强最后一跳 + 写明「抓得住/抓不住」(M292 r1)
复审与塔的门禁在本 worktree 报了一条 `left: 120s / right: 300s`
(`changed_settings_reach_the_engine_config_and_the_budget`)。归因结论:**不是源码缺陷**,
是目标目录里跑到了不属于这棵树的 `unlucky_core` 测试二进制。本轮只做两件事:
## 1. 最后一跳补强(presenter)
`the_three_timeout_keys_travel_from_the_file_to_the_engine_config` 此前是自己拼
`tuning.apply_to(EngineConfig::default())`,即「调优 → 引擎」这一跳是**用例自己接的**,
守不住「宿主有没有把调优交给 core」。现在改走 GUI 的生产装配点
`crate::host::engine::engine(&env)`(内部 `apply_tuning` → `shared::set_tuning` → 按数据根重建),
断言读 `engine.config()`。这一步断了(宿主没调 `apply_tuning`、或 `shared` 装配点没用
`apply_to`),三条断言全红。
## 2. 用例文档写清边界(config/tests.rs)
`changed_settings_reach_the_engine_config_and_the_budget` 的文档补上返工取证:
- **抓得住**(三键逐一变异,删掉 `apply_to` 里对应赋值即红):
`response_timeout` ⇒ 278 行 `60s/180s`;`chunk_stall_timeout` ⇒ 279 行 `120s/300s`;
`min_avg_throughput` ⇒ 280 行 `32768/16384`。另抓 `from_raw` 的 KiB→字节换算与
`chunk_job_budget` 忽略下限。
- **抓不住**:①宿主有没有调用 `tuning`/`apply_to`(前半段归宿主用例);②跑的是不是这棵树的
二进制(编译期常量与代码内容都不在它视野里 —— 本轮就栽在这里)。
`config/tests.rs` 因此从 394 → 398 行(仍在 400 硬线内)。
2026-11-13 04:06:42 +08:00
..
2026-11-04 00:21:19 +08:00
2026-11-12 14:21:30 +08:00
2026-11-13 04:06:42 +08:00
2026-11-05 13:36:44 +08:00
2026-11-05 06:35:03 +08:00
2026-11-08 17:03:13 +08:00
2026-11-11 14:25:26 +08:00
2026-11-04 00:21:19 +08:00
2026-11-12 19:55:52 +08:00
2026-11-02 09:29:31 +08:00
2026-11-05 19:09:53 +08:00
2026-11-07 17:01:13 +08:00
2026-11-05 13:36:44 +08:00
2026-11-11 14:56:26 +08:00
2026-11-05 05:08:35 +08:00
2026-11-08 17:03:13 +08:00
2026-11-09 18:42:41 +08:00
2026-11-07 10:36:35 +08:00
2026-11-11 13:29:56 +08:00
2026-11-02 10:11:55 +08:00
2026-11-02 09:29:31 +08:00
2026-11-02 09:29:31 +08:00