fix(web): ask for the restart that makes an update take effect - #484
fix(web): ask for the restart that makes an update take effect#484ChuckBuilds wants to merge 1 commit into
Conversation
The update button pulls new code and restarts nothing. There is no systemctl, restart, reload or reboot anywhere in the 172-line git_pull handler -- it stashes, pulls, installs changed requirements, re-removes plugins the user had uninstalled, and returns "Code updated successfully." Meanwhile both services go on running the code they loaded at boot. So the display keeps rendering the old build, the web interface keeps serving the old build, and the user is told the update worked. Nothing on screen suggests otherwise, and the next reboot is what actually applies it -- whenever that is. The affordance for this already exists: the restart-pending banner, raised after main-config saves, with a Restart Now button wired to the display service. A code update is a stronger reason to show it than a config save is. The response now reports restart_required, and applyUpdate raises the banner with wording for a code update rather than a config save. The banner's message became a parameter and is persisted next to the flag, since it outlives the page that raised it. restart_required is only true when the pull actually moved HEAD. "Already up to date" is a success too, and prompting after a no-op would train users to dismiss the prompt unread. This covers the display service, which is what the Restart Now button drives and what users notice. The web interface still picks up its own new code on its next restart; restarting it from inside a request it is serving is a larger change than this one. Reverting the flag fails the test that a pull which moved HEAD asks for a restart. 290 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
|
Warning Review limit reached
Next review available in: 23 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 7 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
Superseded by #485, which combines the seven api_v3.py PRs so they do not conflict with each other. Every change from this PR is verified present on that branch; the branch here is untouched if you want to compare. |
1 participant
Third in the update-path series (#482, #483). Those cover checkouts that cannot pull. This one covers a pull that succeeds and still changes nothing the user can see.
The update button restarts nothing
The
git_pullhandler is 172 lines and contains zero occurrences ofsystemctl,restart,reload,rebootorservice:It stashes, pulls, installs changed requirements, re-removes plugins the user had uninstalled — and returns "Code updated successfully."
Both services go on running the code they loaded at boot. The display keeps rendering the old build; the web interface keeps serving the old build. The user is told the update worked, sees no change, and the next reboot is what actually applies it — whenever that happens to be.
The affordance already exists
The restart-pending banner is raised after main-config saves ("Configuration saved — restart the display to apply the changes") with a Restart Now button already wired to
restart_display_service. A code update is a stronger reason to show it than a config save is, and it was the one path that never did.What changed
restart_required, andapplyUpdateraises the banner with wording for a code update.sessionStorage— it outlives the page that raised it, so the text has to survive a reload too.restart_requiredis true only when the pull actually moved HEAD. "Already up to date" is a success as well, and prompting after a no-op would train users to dismiss the prompt unread.Scope
This covers the display service — what the Restart Now button drives, and what users actually notice. The web interface still picks up its own new code on its next restart. Restarting it from inside a request it is currently serving is a bigger change with real failure modes, and it belongs in its own PR rather than smuggled into this one.
Verification
Three tests driving the endpoint with git mocked: HEAD moved → asks for a restart; already-up-to-date → does not; failed pull → does not. Reverting the flag fails the first. 290 tests pass.
Touches a different region of
api_v3.pythan #482 (resolve_pull_command) and #483 (check_for_update), so all three are independent.