ADFA-4842: module install — stop and restart the server around the runroles - #299
Merged
Conversation
…eat/ADFA-4842-module-restart
… REST one Two bugs came from recycling the REST 'finishing setup' flow for proot module installs, which have the OPPOSITE server assumption (REST runs on the live server; a module install stops it and runs its own proot). Fixed, scoped to a module install (moduleInSession) so REST and REST+proot (mixed), which already work serialized, are untouched: 1. Loop escape: onBackPressed only trapped on the derived prootActive(), which has gaps, so Back could walk back through the hub/Settings steps. Now a module install hard-locks the index for its whole (durable) session — Back only ever backgrounds the app; reopening resumes here. 2. 'Starting services' during a proot install: readyPoll waited for the REST engine (apiReady) and showed REST wording even though the server is intentionally down — and on reopen sat there implying it should start the server (a second proot) mid-runrole. A module install now skips the REST readiness gate entirely (the runrole queue drives progress; the server is restarted only after DONE) and the status reads 'Modules are installing', with 'Starting services' reserved for the real post-DONE restart.
…eat/ADFA-4842-module-restart
…orall/iiab-android into feat/ADFA-4842-module-restart
…ad server Regression analysis (3rd time landing on a dead Library after a module install): the post-install 'start + wait' call (SetupProgressActivity.ensureServerUpForModules → handleServerLaunchClick) is intact. The gap is the DESTINATION: goHome returns to the REUSED LibraryActivity via onNewIntent, and only onCreate carried the server autostart — so a reused Home never (re)starts the server and simply inherits whatever state was left. When the earlier cold-boot recreate was reverted (fresh onCreate → reuse), that destination-side start was lost. Fix: onNewIntent now runs the same guarded autostart as onCreate (extracted to maybeAutostartServer). Returning Home after any install drives the server up when it's installed and down, never inheriting a dead state. No-op when already alive/starting or an install/guard is in flight. (A genuine pdsm-start failure is separate and needs the device log; the 45s server-up timeout in the index also masks such a failure as success — noted for follow-up.)
…oggle)
Device log root cause: after the last runrole, the index called handleServerLaunchClick — a
TOGGLE (start if !alive, STOP if alive). The runrole proot exits with --kill-on-exit, killing
the services it had (re)started, but the app's cached 'alive' still read TRUE for a moment, so
the toggle STOPPED the environment ('Stopping IIAB environment gracefully' in the log) and the
user landed on a dead Home; ~45s later Home's autostart recovered it.
Mechanism (documented in code so it isn't broken lightly): each module runrole runs its own proot
= clean start -> tasks -> clean stop, so the environment is DOWN when the batch ends (correct for
several modules in series). The INDEX is the actuator that brings it back after the LAST module —
UNCONDITIONALLY. REST content installs run on the live server (never down); different world.
- ServerController.startEnvironment(): unconditional pdsm start, extracted from the toggle's start
branch (handleServerLaunchClick still calls it, keeping toggle semantics for the UI button).
- SetupProgressActivity.ensureServerUpForModules() calls startEnvironment() (never the toggle),
with a comment block explaining why.
- serverUpPoll timeout no longer declares silent success: it surfaces a failure (Finish + note),
so a server that won't come up is reported, not hidden.
- LibraryActivity stays a MONITOR (reverted the onNewIntent autostart): Home never starts the
server; the actuators are app launch (onCreate) and the index.
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
1 participant
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.
What
A module (proot) install runs its runroles with the server stopped, so it needs its own
handling in the setup index rather than reusing the REST content flow (which assumes the
server stays up).
Changes
maps-only batch skips it. Clears the install guard before signaling DONE.
to start services mid-runrole, restarts the server after the queue finishes, and redirects
only once the REST core answers — landing on the Library (Home) tab.
walking back into a half-built flow.
during the post-DONE restart, with an animated ellipsis (reusable util/EllipsisAnimator).
Verification
progress, the server restarts on its own, and it lands on a live Home (previous + new
modules).
Supersedes
feat/ADFA-4842-module-mgmt(#255).