# 🟡 `build-reborn test` takes about an hour — and I left two runaways

**Status:** ✅ measured. Two facts, one of them my own mess.

## The gate the brief names does not complete

`build-reborn test` (`cargo test --workspace` with `SYLPHEED_DISC` wired up) is
the verification gate. It contains a disc test that decodes **every `.xpr` in
`hidden/resource3d` — 166 files, 1.4 GB** — through the full `Xbg7Model`
anchoring path:

```rust
#[test]                                   // NOT #[ignore]d
fn twin_pairs_do_not_share_a_buffer() {
    …for f in &files { … Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) … }
```

Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing.

### 🔴 "Cannot terminate" was too strong — corrected

It terminates; it is merely heavy, and I said the stronger thing before measuring
it. Timing `sylpheed-cli mesh info` on each of the 166 files with a 25 s cap
([`data/slow-xpr-files.txt`](data/slow-xpr-files.txt)):

| | |
|---|---|
| files scanned | 166 |
| exceeding 25 s | **19** — `Hangar`, 17 `Stage_*`, `ptc_pack` |
| `Stage_S02` timed to completion | **144 s**, `rc = 0` |

So nothing hangs. Nineteen heavy containers at roughly two minutes each is
**~45–60 minutes** for one pass, before the 147 fast ones. The observed 3 h 26 m
was that work running at a **load average of 9–14** — inflated by my own two
duplicate runs competing with each other and with this one. The runaways did not
merely coexist with the slowness; they multiplied it.

⚠️ The practical conclusion is unchanged and only the wording softens: an
hour-scale suite is not an iteration-scale gate.
Its sibling in the same file, `shared_resources_decode_identically_in_every_container`,
walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's
cost is easy to underestimate from a glance at the file.

⚠️ **Consequence for anyone using this gate:** every "green run" reported in this
corpus from a workspace test is necessarily **partial** unless it explicitly says
the suite terminated. `cargo test -p sylpheed-formats` reaches ~131 tests in a few
minutes and then sits in this one; the workspace run is the same picture. Quote
the suite count and the elapsed state, not the word "green".

🟡 Not proposed here: `#[ignore]`-ing it, or bounding it to a sample of the 166.
Both change what the suite asserts, which is the project's call and not a
side-effect of an audit.

## 🔴 And I left two of them running for four hours

Two `cargo test -p sylpheed-formats` runs launched detached in earlier iterations
never exited, because they were sitting in this test. At the moment they were
found:

| pid | elapsed | child | CPU time | %CPU |
|---|---|---|---|---|
| 103375 | 4 h 12 m | `mesh_consistency_disc` | **3 h 26 m** | 89.3 |
| 99965 | 4 h 39 m | `pak_idxd_disc` | 1 h 16 m | 93.8 |

Load average **14.18** on 12 cores. Killed; load fell to **9.68** within a
minute, and the legitimately-running workspace suite was checked first and left
alone.

### 🔴 What this does NOT explain

It is tempting to pin the session's emulator troubles on this, and the
measurement says no. `screenshot` cost **0.49 s** with both runaways live and the
emulator stopped, against the **10.8 s** measured earlier with the emulator
running. So the 92× figure in
[capture-harness-status](capture-harness-status.md) really was emulator
contention, and the runaways were a background tax on top — not the cause. The
black surface and the unreachable title stand as measured, with their own
controls.