Symptom
`zig build test` on current main fails 1 test out of 540:
```
test.issue-44: snapshot stale after working tree changes cause stale query results — error.OutOfMemory in cloneOutline @ src/explore.zig:1297
src/explore.zig:1297:29: cloneOutline
const copied_path = try allocator.dupe(u8, src.path);
src/explore.zig:1263:16: getOutline
return try cloneOutline(outline, allocator);
src/tests.zig:3680:5: test.issue-44: snapshot stale after working tree changes cause stale query results
try testing.expect(results.len == 1);
Build Summary: 5/7 steps succeeded (1 failed); 539/540 tests passed (1 failed)
```
Reproduced on main with two different seeds (0xfe98e104 and 0xc6b22715), so it's not seed-dependent.
Hypothesis
The OOM is at the first `allocator.dupe` in `cloneOutline` — there's nothing prior to it inside the test that would leak. `testing.allocator` has a fail-on-quota behavior to catch leaks across the suite. So the most likely cause is a leak in an earlier test that exhausts the test allocator, causing the FIRST allocation in `test.issue-44` to fail.
Failing Test
`test.issue-44` itself (already in `src/tests.zig:3680`) — fails reproducibly when run inside the full suite.
Suggested next step
Run the test suite with leak-detection enabled (or bisect by running test subsets) to find which preceding test leaks memory that survives into `test.issue-44`. Once identified, fix the missing `deinit()` / `defer` there. The OOM at `cloneOutline:1297` is the symptom — `cloneOutline` itself looks correct (proper errdefer chain).
Why this matters
A `zig build test` that always shows "1 failed" is noise that masks real regressions. Anyone touching the test suite has to remember "the snapshot OOM is preexisting, ignore it" — exactly the kind of thing that hides a second failure when it appears.
Symptom
`zig build test` on current main fails 1 test out of 540:
```
test.issue-44: snapshot stale after working tree changes cause stale query results — error.OutOfMemory in cloneOutline @ src/explore.zig:1297
src/explore.zig:1297:29: cloneOutline
const copied_path = try allocator.dupe(u8, src.path);
src/explore.zig:1263:16: getOutline
return try cloneOutline(outline, allocator);
src/tests.zig:3680:5: test.issue-44: snapshot stale after working tree changes cause stale query results
try testing.expect(results.len == 1);
Build Summary: 5/7 steps succeeded (1 failed); 539/540 tests passed (1 failed)
```
Reproduced on main with two different seeds (0xfe98e104 and 0xc6b22715), so it's not seed-dependent.
Hypothesis
The OOM is at the first `allocator.dupe` in `cloneOutline` — there's nothing prior to it inside the test that would leak. `testing.allocator` has a fail-on-quota behavior to catch leaks across the suite. So the most likely cause is a leak in an earlier test that exhausts the test allocator, causing the FIRST allocation in `test.issue-44` to fail.
Failing Test
`test.issue-44` itself (already in `src/tests.zig:3680`) — fails reproducibly when run inside the full suite.
Suggested next step
Run the test suite with leak-detection enabled (or bisect by running test subsets) to find which preceding test leaks memory that survives into `test.issue-44`. Once identified, fix the missing `deinit()` / `defer` there. The OOM at `cloneOutline:1297` is the symptom — `cloneOutline` itself looks correct (proper errdefer chain).
Why this matters
A `zig build test` that always shows "1 failed" is noise that masks real regressions. Anyone touching the test suite has to remember "the snapshot OOM is preexisting, ignore it" — exactly the kind of thing that hides a second failure when it appears.