feat(devices): live agent-update progress in the Update agent dialog (VAPP-62) #74
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VAPP-62-live-update-progress"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Web-UI consumer of the agent-update progress stream. The agent emits progress (VA-97, merged) and the server relays it to browsers as an
{"action":"event","event":{"action":"agentupdate",...}}frame (VS-77, merged). This renders that stream in the Update agent dialog, which was previously fire-and-forget: it showed one static "Update sent..." line, so a failed update looked identical to a successful one.Changes
live.rs:decode_framerecognizes the innerevent.action == "agentupdate"and parses{nodeid, session, phase, received, total, detail}into a newUpdateProgress. A newLive::update_progresssignal (full node id -> latest progress) is patched by the wasm driver, mirroringconnectivity.device_detail.rs: the modal stays open after the push. When a stream is arriving for this node it shows the phase label, a download progress bar (received/total), and a distinct terminal state: a failure line with the agent/server-supplieddetail, or a "verified, restarting" line. When no stream arrives (device skipped as already-current, or a pre-VA-97 agent) it falls back to the existing static ack summary, so behavior never regresses.use_effectrefetches the device once, after the terminalrestartingphase plus the agent's reconnect, so the "Agent" fact and the VAPP-61 current-vs-target comparison reflect the new build without a manual reload.Acceptance criteria
live.rsdecodesagentupdateand exposes per-node progress viaLive::update_progress. ✔just pre-commit(fmt + clippy -D warnings on server and wasm + tests) passes. ✔Verification note
Covered by unit tests on the frame decoder and progress helpers plus the full
just pre-commit. Not exercised end-to-end against a live update in a running browser, so the effect-driven refetch timing (restarting + reconnect) is reasoned, not observed.Depends on VS-77 (merged) which depends on VA-97 (merged). Relates to VAPP-61 (merged; provides the current/target version block this builds on).
The Update agent modal was fire-and-forget: it showed one static "Update sent..." line from the push ack, so a failed update looked identical to a successful one. It now watches the live progress stream the agent emits (VA-97) and the server relays as an `agentupdate` event (VS-77). - live.rs: `decode_frame` recognizes the inner `event.action == "agentupdate"` and parses `{nodeid, session, phase, received, total, detail}` into a new `UpdateProgress`. A new `Live::update_progress` signal maps full node id -> latest progress, patched by the wasm driver like `connectivity`. - device_detail.rs: the modal stays open after the push and, when a stream is arriving for this node, renders the phase label, a download progress bar derived from received/total, and a distinct terminal state - a failure line (with the agent/server detail) or a "verified, restarting" line. When no stream arrives (device skipped as already-current, or a pre-VA-97 agent), it falls back to the existing static ack summary, so behavior never regresses. - A guarded `use_effect` refetches the device once, after the terminal `restarting` phase plus the agent's reconnect, so the "Agent" fact and the VAPP-61 current-vs-target comparison reflect the new build without a manual reload. Tests: `decode_frame` for downloading/failed/missing-nodeid agentupdate frames, and `UpdateProgress` percent/phase-label helpers. `just check` (fmt + clippy -D warnings on server and wasm + tests) passes. #VAPP-62 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>