When the pkg update sweep fails, fall back to per-package updates and name the offending root in the banner

by adom

Registry-native cross-agent auto-update hook, plus claude-rc, the keeper for Claude Remote Control. Keeps adom/core apps and skills current from wiki.adom.inc on every Claude Code and Codex prompt, and keeps `claude rc` alive so users can open AI threads on their container from the Claude mobile app or claude.ai/code.

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed feature request

Drew Owens · 1mo ago ·closed by Colby Knox

Observed with adom/hook 1.3.2 on 2026-09-02, alongside adom-wiki-cli 1.7.22.

What happens

The hook runs adom-wiki pkg update (the no-arg sweep) and then adom-wiki pkg install adom/core. When one installed root has an unresolvable dependency (see the adom-wiki-cli issue filed the same day: hardware BOM dependencies resolved as installable packages), the sweep aborts on its first batch resolve and applies nothing. The core install still succeeds, so adom/core and its dependencies stay current, but every non-core package silently drifts. On this container four packages sat behind (adom-bridge, pup-bridge, fusion-bridge, adom-shotlog) until they were updated by hand, one at a time.

The hook does the right thing by surfacing the failure loudly. The gap is that the failure mode it surfaces is "the sweep broke", not "these packages are behind and this one root is why", and the fleet keeps drifting until a human reads the log.

Suggested changes

When the sweep exits non-zero, fall back to pkg outdated --json and update each listed package individually with pkg update <ref>. That path is tolerant today, so the fleet stops drifting even while the sweep bug exists.
Name the offending root in the banner. The log already contains the registry error with the dependency name; the hook could grep the NOT_AN_INSTALLABLE_PACKAGE hint and print "sweep blocked by (depends on )". As it stands the banner points at pkg install adom/core, which succeeds and therefore misleads.
Optional: treat "core current, sweep failed" as a distinct status (warning rather than failure), since the two legs answer different questions.

This is a fleet-wide condition: any container with a hardware page installed as a package hits it on every publish.

1 Reply

Colby Knox · 1mo ago

Resolved across three layers; hook side shipped as adom/hook 1.3.3.

The root cause you filed the same day (adom-wiki-cli#46) is fixed where it lived, which changes what this issue needs:

CLI 1.7.25: the no-arg sweep no longer aborts on this class. An unresolvable page-layer dep now gets the same skip-and-continue treatment as missing/forbidden/conflict/cycle roots: the sweep strips every installed root that transitively declares it, warns NOT_INSTALLABLE_SKIPPED naming both the dep and the declarers, and keeps updating everything else. Verified against your exact chain (fabricated installed state with feeder-reader + feeder-reader-library + an outdated package): 1.7.24 exits 1 and applies nothing; 1.7.25 exits 0, updates the outdated package, and names the skipped declarers in the summary. Your four drifting packages stop drifting the moment the fleet CLI updates, with no hook change at all.

CLI 1.7.26 + adom/wiki#177 (staged, prod on next tag): the resolver skips page-layer BOM deps during closure expansion entirely, so even a strict install of feeder-reader resolves clean with the components listed in a skip hint.

On your three suggestions:

1 (per-package fallback loop in the hook): declining this one deliberately. Per-package updates bypass the batch resolver's cross-package conflict detection, and a shell-level fallback would mask exactly the class of failure this hook's own history (the four-day silent outage) taught us to surface. The contract instead is that every sweep-fatal failure class gets a named, tested degrade arm in the CLI; there are five now, and anything that still kills the sweep is a genuinely unknown error that should stay loud.

2 (name the offending root): the CLI now does this itself, and those warning lines land in the hook's log, so the banner's "Recent output" tail carries them. The remaining hook defect you spotted was real though: the banner's static remedy said 'pkg install adom/core' even when that leg had succeeded and the sweep was what broke. Fixed in 1.3.3: the status file records which leg failed (sweep vs core-install) and the banner prints the matching wording and retry command.

3 (distinct status for "core current, sweep failed"): delivered by the same change. A sweep-leg failure now banners as: "the last background auto-update's PACKAGE SWEEP failed (exit N); adom/core itself is current, but non-core packages may be drifting behind wiki.adom.inc. See why with 'adom-wiki pkg update'." Legacy numeric status files keep the old wording, so mixed-version fleets read fine.

All four banner shapes (sweep leg, core-install leg, legacy numeric, success-silence) exercised against the shipped script before publish.