Repository navigation
The detached sweep writes its notices to a null descriptor #480
Description
Activity
- added a parent issue
on Aug 25, 2026 Resolved: the record. A per-repo last-sweep note in
metadata.jsonbesidelast_fetched, overwritten on every sweep, read bydl --lsand--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--lsis 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::detachnulls all three fds (devlaunch-runner/src/lib.rs:660) and the--update-cachechild'ssay()iseprintln!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 fromconfig.tomlon 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
--lsis the cheapest thing that ends it.- 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 (
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_fetcheshas one production caller (rust/dl/src/commands.rs:334), reachable only as the hiddendl --update-cache, spawned only atflows/lifecycle.rs:352viarunner.detach(...), andProcessRunner::detachsetsstderr(Stdio::null())atrust/devlaunch-runner/src/lib.rs:637.So every notice the background sweep raises goes to a null descriptor.
FetchingUpdatesandFetchedUpdatesare equally nulled, and so isCacheNotice::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:
metadata.json; a per-repo last-sweep note besidelast_fetchedis a place a futuredl --lscould 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-refsplateaus 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.