Repository navigation
fix(docker): keep "Check for updates" active for the full walk (v0.8.3) - #14
Merged
Merged
Conversation
The check-updates status poll cleared the "Checking…" state on its first 2s tick: a `return` inside the try fell through to a `finally` that reset _checkingUpdates. On a 40+ container host the button flipped back to idle almost immediately while the per-image registry walk was still running — the "check runs too quickly / not in sync with N containers" symptom. - Remove the misplaced finally; clear _checkingUpdates only on genuine terminal paths (completed, poll error, watchdog). - Conclude only once the run has actually finished: observed running:true, or a finishedAt newer than a pre-launch baseline (keeps fast hosts snappy). - Turn the 60s hard cap into an inactivity watchdog reset on each running:true, so a long but live walk isn't cut off mid-flight (which also avoided reading stale `updated` flags from a half-written cache). - Extract checkUpdatesCompleted() pure helper + 5 unit cases. Backend left untouched — verified correct against stock getAllInfo / reloadUpdateStatus on a live host. Bump to v0.8.3. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…hdog The v0.8.3 fix extracted checkUpdatesCompleted() and unit-tested the decision, but the regression itself lived in the poll *loop* wiring (_pollCheckUpdates) — which had no test. Add an integration test that drives the real loop with fake timers + a mocked actions module (keeping the real checkUpdatesCompleted), pinning the behaviour the pure helper can't catch: - button stays "Checking…" across a premature running:false → running:true → done (the exact first-tick moment the old `finally` reset it), - fast-host conclude on a fresh finishedAt, - poll error releases the button, - inactivity watchdog bails only after POLL_MAX_MS of no sign of life, - a live worker runs well past the old 60s hard cap, - a hidden tab pauses without tripping the watchdog. Also fix a hidden-tab edge in _pollCheckUpdates: the watchdog check ran before the document.hidden check, so a backgrounded tab during a long walk counted as "no sign of life" and bailed mid-flight (refreshing a half-written cache — the stale-flag symptom this loop exists to avoid). Move the hidden check first and grant a fresh watchdog window on return to visibility via a wasHidden flag. Full TS suite green (462 passed); Biome clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Patch v0.8.3 — fix the
/Docker"Check for updates" button finishing too quicklySymptom
On a 40+ container host, "Check for updates" looked like it finished in ~2 seconds — out of sync with the real per-image registry walk, which takes much longer.
Root cause (front-end, deterministic)
The backend is correct: stock
DockerTemplates::getAllInfo($reload=true)callsreloadUpdateStatus($image)per container (the real HTTPS digest fetch), confirmed against the live host. The bug was in the status-poll loop inmd-docker-page.ts:A
returninsidetrystill runsfinally, so_checkingUpdates(a Lit@state()) was reset after the first 2s tick. The button reverted to idle while the worker kept walking in the background. A secondary issue:POLL_MAX_MSwas a hard 60s total cap, shorter than a real 40+ container walk, so it could also cut the post-check snapshot refresh off mid-walk and read staleupdatedflags.Fix
finally; clear_checkingUpdatesonly on genuine terminal paths (completed / poll error / watchdog).running:true, or afinishedAtnewer than a pre-launch baseline (keeps small/fast hosts snappy). Extracted as a purecheckUpdatesCompleted()helper.POLL_MAX_MSinto an inactivity watchdog, reset on eachrunning:true, so a long-but-alive walk isn't cut off; a worker that never establishes (or wedges) its lock still bails.Backend left untouched.
Tests
checkUpdatesCompleted()+ 5 unit cases incheck-updates.test.ts.Verified live
Deployed to a 43-container Unraid host. Triggered "Update all" on the 2 flagged containers: cloudflareddns (running) updated + restarted; Nginx-Proxy-Manager (stopped, autostart off) updated + correctly left stopped.
unraid-update-status.jsonflipped bothfalse→trueandwebui-infowas rewritten — badges clear as expected.Release
Bumped
package.json,package-lock.json, and the.plg<!ENTITY version>to 0.8.3, with a matching###v0.8.3changelog entry in the.plg<CHANGES>block. Tagv0.8.3to publish after merge.🤖 Generated with Claude Code