Files
ElyOffice/tasks/reviews/C01.2c-r2.md
T

15 lines
2.4 KiB
Markdown

FAIL
Ran: `cargo test -p ely-platform -p ely-ui` (all pass, including `tests/startup.rs` and the harness-less `tests/startup_panic.rs`: "2 cases pass"), `cargo clippy -p ely-platform -p ely-ui --all-targets` (clean). I also ran the `startup_panic` "launch" child without `ELY_NO_DIALOG`. A system alert came up that named ElyDoc, the reason and a log path, and it blocked until the process was killed. Read gpui 1a28cff `gpui_apple/src/metal_renderer.rs:190-210`: `graphics::check` uses the same `Device::all()` / `system_default()` test that gpui uses before its `process::exit(1)`.
Round 1:
1. Startup panic aborting on macOS: fixed. `startup::guard` (startup.rs:36-48) calls `fail` from the panic hook. That runs before the non-unwinding abort. `startup_panic.rs` "launch" proves it inside gpui's launch callback: exit 1, stderr text and log line.
2. Metal device missing, so gpui exits silently: fixed. `graphics::check` runs before `run` (run.rs:17-19), and its probe matches gpui's own. The failure branch is honestly listed under 未验证.
3. Late panics labelled as a failed start: fixed. The `STARTED` flag is set on the first frame (run.rs:48). `startup_panic.rs` "late" shows a later panic exits 101 with the ordinary panic text and no "could not start".
4. Unbacked claims in TASKS: fixed. The window-open branch and the probe-failure branch moved to 未验证. The panic path has a test.
New:
1. crates/ely-platform/src/startup.rs:19-22 — `fail` names a log file it has not checked exists. It rebuilds the path from `data_dir(app)` and does not ask where logging actually writes, or whether logging started at all. Scenario A: `~/Library/Application Support/ElyOffice/ely-doc` is not writable. `logging::init` fails and run.rs:15 calls `fail`. The dialog and stderr then say "日志 / Log: …/ely-doc/ely.log", but that file was never created, and the `log::error!` on line 18 goes nowhere because no logger is set. The user is sent to a log that does not exist (rule 2: no default standing in for missing data). Scenario B, seen in this review: the `startup_panic` child logs to its temp dir, yet the dialog points at the real user data dir. Neither test checks the path, so this went unnoticed. Fix direction: have logging record the path it actually opened (for example `init` returns it or stores it), and have `fail` print that path. When logging did not start, say there is no log. Add an assertion on the printed log path to `tests/startup.rs`.