The detached sweep writes its notices to a null descriptor

[blooop]

Found while reviewing #470 (PR #478). The invisibility is pre-existing and systemic; #470 was only the first change that wanted to promise a warning the sweep cannot deliver, and it settled by describing the gap rather than closing it.

Question

The whole path, traced: sweep_repo_fetches has one production caller (rust/dl/src/commands.rs:334), reachable only as the hidden dl --update-cache, spawned only at flows/lifecycle.rs:352 via runner.detach(...), and ProcessRunner::detach sets stderr(Stdio::null()) at rust/devlaunch-runner/src/lib.rs:637.

So every notice the background sweep raises goes to a null descriptor. FetchingUpdates and FetchedUpdates are equally nulled, and so is CacheNotice::RefsNotPacked, added by #470. The sweep can tell you nothing about anything it does.

What makes this worth a decision rather than a patch: the sweep is detached on purpose, so it does not hold up a launch, and a detached process writing to the terminal it detached from is its own bug. The candidates differ in what they promise:

• Nowhere. Accept that the sweep is silent, and delete the notices it cannot deliver rather than raise them into a void. Smallest, and honest, but it forfeits the only account of what the cache did between launches.
• A file. The sweep writes its notices under the cache, and something surfaces them on the next foreground run. Costs a rotation question, and a file nothing reads is straggler data under principle 2.
• The record. A refusal already touches metadata.json; a per-repo last-sweep note beside last_fetched is a place a future dl --ls could read it from, with no new file and no rotation.

Principle 2 has an angle here that is easy to miss: a warning nobody can read is itself accumulation, in that the condition it reports goes on being true forever with nothing escalating. #470 measured that a permanently failing pack-refs plateaus rather than grows (loose refs are rewritten in place, not appended), so the bound is real and this is not urgent. But "nothing escalates, ever" is the property to decide on purpose.

How the answer gets tested

Whichever way it goes: a sweep whose pack refuses, asserting the refusal reaches whatever the answer says it should reach. Today no test can distinguish the notice being raised from the notice being read, which is part of the finding.

[blooop]

Resolved: the record. A per-repo last-sweep note in metadata.json beside last_fetched, overwritten on every sweep, read by dl --ls and --ls --json. Built by #508.

Decided with the human against actual usage: nobody ever watches the detached process, and the only surfaces anyone reads are launch output and --ls, so --ls is where a background complaint has any chance of meeting an eye.

The other two candidates, refused:

• Nowhere forfeits the only account of what the cache did between launches, and deletes a notice Pack the bare caches' refs on the sweep #470 deliberately built (CacheNotice::RefsNotPacked, repo_manager.rs:256, raised at :1435).
• A file pays principle 2 to satisfy principle 2: a rotation question, and a log nothing reads is itself straggler data. The record needs neither, because overwrite-per-repo is bounded by construction.

Two facts verified before deciding, so the build inherits them rather than rediscovering them: ProcessRunner::detach nulls all three fds (devlaunch-runner/src/lib.rs:660) and the --update-cache child's say() is eprintln! into that null (dl/src/commands.rs:346, :355), so today the sweep's notices reach nothing, exactly as this ticket traced. And there is no persist-and-print precedent to copy: the #481 retired-key notice re-derives from config.toml on every run and writes nothing. #508 introduces the first background-learned condition that survives to a foreground run, on purpose, and the ticket says so.

The ticket's own principle-2 angle stands as the deciding one: a warning nobody can read is accumulation of the condition it reports. The record plus --ls is the cheapest thing that ends it.