feat(control): DIG auto-update beacon RPC proxy (control.updater.*)#35
Merged
Conversation
Surfaces the dig-updater beacon's status/control over the existing control.*
WS/HTTP surface (same #432 control-token auth), so the extension/hub Updates
UI (#516) can show + drive it:
- control.updater.status reads the beacon's world-readable status.json
(dig-updater SPEC §13.2) directly off disk and returns it verbatim;
{"installed": false} when absent (never an error).
- control.updater.setChannel / .pause / .resume shell the already
elevation-gated dig-updater CLI (this service runs privileged, so it
satisfies that elevation check the same way an Administrator/root
operator would).
- control.updater.checkNow shells `dig-updater check --now` for a
synchronous on-demand pass.
A thin proxy only — no beacon trust/install/verify logic is reimplemented.
The CLI is resolved by an absolute path (override, beside dig-node, or a
conventional install dir), never a bare name through PATH. Both the status
file and the CLI's --json output are forwarded as opaque JSON.
Tests: unit coverage for status.json present/absent/corrupt + binary
resolution + param validation (src/updater.rs); a real-child-process
integration suite against a fake_beacon_cli fixture exercising every CLI
outcome (success/declined/malformed) (tests/beacon_cli_process.rs); wired
e2e over the real HTTP server proving the auth gate + a real mutation
(tests/server.rs). SPEC.md §7.13 documents the new methods.
Closes #515.
Co-Authored-By: Claude <noreply@anthropic.com>
be07807 to
73abad0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Beacon epic #504, work-unit #515: dig-node proxies the DIG auto-update beacon (
dig-updater, v0.6.0) status/control over the existingcontrol.*WS/HTTP surface, so the extension/hub Updates UI (#516) can drive it.control.updater.status— reads the beacon's world-readablestatus.json(SPEC §13.2) directly off disk and returns it verbatim; a graceful{"installed": false}when absent (never an error). Read directly (not via the CLI) since this is polled frequently.control.updater.setChannel/control.updater.pause/control.updater.resume— shell the elevation-gateddig-updaterCLI (the node service already runs privileged, so it satisfies that elevation check the same way an Administrator/root operator would).control.updater.checkNow— shellsdig-updater check --nowfor a synchronous on-demand pass.A thin proxy only — no beacon trust/install/verify logic is reimplemented; both the status file and every CLI
--jsonresult are forwarded as opaque JSON (the beacon's own schema-versioned wire contract is designed precisely for this). Gated by the existing #432 control-token auth (samecontrol.*namespace, same token — zero new auth surface).The
dig-updaterCLI is resolved by an absolute path — an explicit env override, else beside this runningdig-nodebinary (the shared bin dirdigstore/dig-node/dig-dnsalready use), else a per-OS conventional install root — never a bare name throughPATH(matching the beacon's own install-path discipline, SPEC §8.3).Blast radius checked
crates/dig-node-service/src/control.rs—dispatch_control's match arms (newcontrol.updater.*cases only; every existing arm/test untouched).crates/dig-node-service/src/meta.rs—methods()catalogue (additive entries;openrpc_drift_guard.rs'sis_shell_onlyalready treats anycontrol.*prefix as shell-only, so no drift-guard changes needed).crates/dig-node-service/src/lib.rs— one newpub mod updater;.crates/dig-node-service/src/updater.rs— no existing callers (net-new surface).tests/server.rs— two new tests appended to the existing CONTROL-plane section; no existing test touched.Test plan
src/updater.rs, 8 tests): status.json present/absent/corrupt, the default per-OS status-dir convention, param validation, binary-resolution override + missing-file handling, every mutation'sNOT_SUPPORTEDwhen no CLI resolves.tests/beacon_cli_process.rs, 6 tests): afake_beacon_clifixture binary (built alongside the test target,tests/fixtures/fake_beacon_cli.rs) stands in for the realdig-updaterCLI's--jsonI/O contract — exercises a REAL spawn for setChannel/pause/resume/checkNow, plus declined and malformed-output paths.tests/server.rs, 2 tests):control.updater.status/checkNowwithout a token →-32030 UNAUTHORIZED; a full status round-trip (absent → present, forwarded verbatim) plus a realsetChannelmutation against the fixture, all over the actual axum server.cargo fmt --checkclean,cargo clippy --all-targets --all-features -D warningsclean, full cratecargo testgreen (162 lib + 6 + 47 + others, 0 failures).cargo llvm-covcould not run locally (a pre-existing environment-only MSVC/CMakelibz-sysbuild failure that reproduces identically on pristinemain— not introduced by this change); CI's Linux coverage gate is unaffected. New code is exercised by 16 dedicated tests across every branch (installed/not-installed/corrupt, success/declined/malformed, missing-param).Version bump
Minor (
0.29.0→0.30.0) —feat:additive new RPC methods, no existing behavior changed.Refs #515, #504.
Co-Authored-By: Claude noreply@anthropic.com