Test harness leaks a temp dir per run — 14,922 accumulated (a directory-count leak, not a disk one)

[MichaelTaylor3d]

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166

Task

The dig-wallet / dig-node test harness leaks a temp directory per run and never cleans it up.
Measured 2026-08-28: 5,976 directories under %LOCALAPPDATA%\Temp\ matching dig-node-* and
dig-wallet-svc-*, each holding a wallet.sqlite plus its -wal and -shm siblings.

Why this is worth a ticket rather than a comment

It is the known cause of ENOSPC incidents on the development machine, and ENOSPC stops every lane
at once rather than failing one of them. A previous sweep reclaimed 62.5 GB from 1,123 leaked test
temp dirs — and the count has since grown to 5,976, so the leak is ongoing and accelerating with
test volume.

It is also invisible to the obvious diagnostic. A top-N-by-size listing shows build caches, not
this: the damage is many small directories rather than a few large ones, so the usual "what is eating
the disk" pass walks straight past it. That is why it went unnoticed long enough to reach four figures.

Where to look

The harness creates these around a temporary WalletDb. Candidates for the leak:

• a TempDir whose guard is dropped early, or bound to _ rather than a named binding, so the
  directory is removed before the test finishes — or leaked because the guard is std::mem::forget-ed
  or moved into something that outlives the assertion
• a test that panics before its cleanup runs (a failing assertion skips a manual remove_dir_all)
• a harness that deliberately preserves the directory for post-mortem inspection and never prunes

The naming (dig-node-<pid>-<n>, dig-wallet-svc-<pid>-<n>, dig-node-origin-test-<pid>-<n>,
dig-node-peernet-<pid>-<n>) suggests several call sites, so expect more than one.

Acceptance

A test run that creates N temp directories leaves zero behind on success, and on failure leaves at
most the ones whose contents a post-mortem needs — deliberately, with the retention stated. Prove it by
counting the directory before and after a full cargo test -p dig-wallet run.

Prefer an RAII guard that cannot be skipped by a panic over a manual cleanup call, since the panicking
case is the one that currently leaks.

Note

The existing 5,976 directories are being reclaimed separately as housekeeping; this ticket is about the
harness that produces them. Reclaiming without fixing means doing it again next week.

Do not touch %LOCALAPPDATA%\DigNode\ while working on this — despite the similar name it is the
running node's live wallet database, not a test artifact.

[MichaelTaylor3d]

Correction to this ticket's own framing — the disk claim was wrong

I filed this citing the leak as "the known ENOSPC cause" and quoting a prior sweep of 62.5 GB from
1,123 dirs. A reclaim run immediately afterwards measured the real numbers, and they do not support
that claim:

category	count	size
leaked test temp dirs	14,922	0.33 GB
lane target/ dirs	13	112.57 GB
.gitnexus indexes	1	0.04 GB

The temp dirs are ~22 KB each. They were 0.33 GB of a 122.66 GB reclaim — under 0.3%. Build caches
were the disk problem; these were not.

What is still true, and is why the ticket stays open:

• The leak is real and larger than first counted — 14,922 directories, not the 5,976 I measured,
  because my count matched only two name patterns and there are more (dig-node-origin-test-*,
  dig-node-peernet-*, dig-wallet-svc-*, and others).
• It is a directory-count leak, not a byte leak. That still matters — it slows directory
  enumeration in %TEMP%, it makes every future disk audit noisier, and 15k directories accumulating
  between sweeps is a harness that never cleans up after itself.
• The acceptance bar is unchanged: a run that creates N temp directories leaves zero behind on
  success, and on failure leaves only what a post-mortem needs, deliberately and with the retention
  stated.

What changes: the priority. This is ordinary maintenance, not an ENOSPC mitigation. Anyone
triaging by disk impact should skip it; anyone fixing the harness for correctness should still fix it.

Recorded rather than edited away, because the original framing is the kind of plausible-but-unmeasured
claim that gets repeated once it is written down — and I wrote it down.