First run: starter-set picker and background installs (#10 part 2a) #71
No reviewers
Labels
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
schaefera/utStudyBIble!71
Loading…
Reference in a new issue
No description provided.
Delete branch "phase1/first-run"
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?
What
With no Bible installed the app shows a starter page: language choice, the pre-ticked set from presets/ (description, licence, size per module), one Download tap, progress per module and overall, errors with Retry.
Installs run in the task runner off the GUI thread; a kill leaves a half-done set that resumes on the next start; the first Bible opens without a restart.
Modules come from CrossWire over HTTPS. Add-on sets are part 2b; preset descriptions are English data and not translated.
#10 (F1) part 2a.
Blast radius
Tier: trunk
Trunk paths touched: core/src/db.rs, core/src/tasks*, core/src/worker*, qt/ (installer.rs, reading_model.rs, build.rs, lib.rs), qml/Main.qml, qml/pages/ReadingPane.qml, tools/e2e/. Leaf parts: StarterPage.qml, po/, core/src/starter*, core/src/presets.rs.
Testing tier: standard (feature, plus test tooling). Downloads write module files outside the process, but only into the app's own data dir (sword/, tasks/), and the e2e cases install from a local repo and read the installed Bible back, so this is not raised to elevated.
Gate / rollback: no flag; revert the merge commit. No migration. The starter page appears only when no Bible is installed; the task runner starts on every launch (its cost is under docs/07 below). A started install resumes from its
.partfiles. db.rs change: the app database is opened one at a time from the start (fixes a first-run "database is locked" race found by starter-fail; has a test). UTSB_TEST_REPO / UTSB_TEST_RATE exist only for the e2e cases (tools/e2e/lib.sh) and are honoured in development builds only.Proof
7e757bd8e7: 6 of 6 green (rust, audit, app, e2e, click, preset-check).cargo make(fmt, clippy, tests+coverage, release check, deny, audit): exit 0, after the review fixes.cargo make app-docker: exit 0. PSS peak 151940 kB normal / 151153 kB slow (budget 165000).cargo make e2e-docker, KJV only and full cache: 14 passed, 0 failed; slow profile 4 passed. New cases starter-install, starter-kill (kill -9 mid-download; after restart the first request is a Rangebytes=557056-1081343), starter-fail (404 shows "the server answered HTTP 404", Retry installs) passed twice in different orders. No case uses the network; tools/e2e/repo-server.py serves packages built from SWORD_TEST_PATH on 127.0.0.1.cargo make i18n: po/ refreshed, 60 translated messages.cargo make click: builds, click-review passes.worker::tests::a_bible_installed_after_no_bible_is_found_by_the_next_open,errors_without_a_bible,the_last_bible_removed_is_no_bible_againFAILED.a_server_error_is_reported_as_a_retry_and_the_download_still_finishesFAILED.a_start_with_unfinished_installs_says_which_before_it_goes_onFAILED.tasks::progress::testsFAILED.starter::tests::a_set_starts_with_its_default_ticks_and_the_bibles_come_firstFAILED.db::tests::concurrent_opens_of_a_new_file_all_succeedFAILED withdatabase is locked.starter-install: FAIL: no 'utsb: starter download' (x1) after 30 s; runner not started with the app:starter-kill: FAIL: no 'utsb: showing' (x1) after 60 s; Retry does nothing:starter-fail: FAIL: no 'utsb: install KJV installed' (x1) after 60 s.database is locked(WAL switch ignores busy_timeout). Fixed by taking the existing in-process lock before the WAL switch; starter-fail then passed 8 of 8 repeated runs.an_error_of_the_queue_stays_until_an_install_moves_again,a_row_says_the_bytes_or_why_it_stopped,a_failure_is_said_in_a_sentence_with_the_detail_in_it,the_test_variables_point_the_app_at_a_local_repository_and_slow_it), but they use new APIs, so they failed to compile before the change rather than failing against the old code.Effect on the docs/07 budgets (measured, amd64 CI image, Xvfb, software GL)
Phone
PR build
0.0.1 phase1/first-run@7e757bd8einstalled on the Volla/Plinius that already has modules:window loaded after 283-351 ms,restored KJV 7421 0.382,showing Ruth 3, andsaved KJV 7421 0.382on suspend. With modules installed the app starts and restores as before and the starter page does not appear.The journal has
QObject::startTimer: Timers cannot be started from another thread, once per launch. Not from this PR: a backtrace on the phone (temporary handler, not committed) puts it in UT's Mir platform plugin (libqpa-ubuntumirclient.so,QTimer::startfrom alibmir1clientthread), and main's build on the same phone logs it too (PR comment 1740). Desktop e2e cannot see it (Xvfb has no Mir).The first-run screen itself is not tried on the phone (modules present). It goes into the post-merge phone checklist on #10, and per docs/09 "On the phone" the owner tries it:
Review
Reviewer: fresh-context
code-reviewat high (review 245 ondff31c6): 6 findings (no high or medium, 6 low), 5 fixed in7e757bd, 0 declined, 0 deferred, 1 answered in this body, 0 left open. Delta reviews: 246 (medium, dff31c6..7e757bd) no findings; 247 (delta after the phone check) empty range, no findings.Review-Confidence: 85/100, the only unproven change is the starter-over-the-picker behaviour (no e2e case, no failing-before check); everything else has fails-without proof and CI is green.
Review 245 findings and answers (author reply: PR comment 1737; delta comment 1739):
Confidence by part
🤖 Generated with Claude Code
Level: HIGH, single pass. Commit
dff31c6, range origin/main...HEAD (3 commits). Blast radius trunk.Files reviewed: core/src/db.rs, presets.rs, starter.rs (+tests), tasks.rs, tasks/exec.rs, tasks/progress.rs, tasks/tests.rs, worker.rs, worker/session.rs, qt/build.rs, qt/src/installer.rs, qt/src/lib.rs, qt/src/reading_model.rs, qml/Main.qml, qml/pages/ReadingPane.qml, qml/pages/StarterPage.qml, tools/e2e/lib.sh, repo-server.py, cases/starter-{install,kill,fail}.sh. Followed the install path through tasks/exec.rs and db/tasks.rs (enqueue, requeue, fail, clean).
No high or medium findings. Checked and found sound: kill mid-download (running rows requeued, Restored event, .part/.state kept on Stopped and cleaned only on Done/Failed/Cancelled, package::installed short-circuit); retry (enqueue deletes the old failed row); NoBible re-checked by each Open so a newly installed Bible shows without restart; DB first-run open serialised by MIGRATING taken before open/WAL.
Findings outside the diff / low:
errorand nothing clears it; it only shows whenstarted, so a transient "tasks: ..." error stays on the page for the session after a later successful install.visiblehas (installer is always set by Main, so no current failure).Answer to review 245 (all low), fixed in
7e757bd:Board; an install that starts, progresses or finishes, or a new Download/Retry, clears it. Test:tasks::progress::tests::an_error_of_the_queue_stays_until_an_install_moves_again.tr(), with German in po/. The detail after the colon comes from the server/system and stays as said. Tests:exec::tests::a_failure_is_said_in_a_sentence_with_the_detail_in_it,a_row_says_the_bytes_or_why_it_stopped. e2e starter-fail now sees "the server answered HTTP 404".Config::from_env(paths, dev)applies them only in a development build (utsb_stamp::SOURCE.is_some()). Test:the_test_variables_point_the_app_at_a_local_repository_and_slow_itnow also checks that a release ignores them.visible). Cosmetic, no test.Re-review of the fixes to review 245. Level MEDIUM, commit
7e757bd, range dff31c6..7e757bd.High/medium findings: none. Low findings: none with a concrete failure scenario.
Checked against review 245:
Not run: build, e2e cases.
Files reviewed: core/src/tasks.rs, core/src/tasks/exec.rs, core/src/tasks/progress.rs, core/src/tasks/tests.rs, core/src/i18n.rs (context), qt/src/installer.rs, qml/Main.qml, qml/pages/ReadingPane.qml, tools/e2e/lib.sh, po/ (names only), sword/src/install.rs (Error enum, context).
Thanks for review 246. No high, medium or concrete low findings, so there is no code change: the head stays
7e757bdand CI on it is green in all contexts (rust, audit, app, e2e, click, preset-check). Since you did not build or run anything, I did: the head built withcargo make click, installed on the phone and launched; it starts (322 ms), restores KJV and saves on suspend. The PR body's Phone section has the details, including oneQObject::startTimerwarning I could not tie to this PR, and says the first-run screen itself still needs a phone try before leaving draft. The PR stays a draft.Phone check of
7e757bd: the build starts, restores KJV and shows Ruth 3, and the starter page stays hidden because modules are installed. The journal also showedQObject::startTimer: Timers cannot be started from another thread, so I traced it.Cause: it does not come from this PR. A backtrace on the phone (temporary message handler, not committed) puts it in
libqpa-ubuntumirclient.so. That is Ubuntu Touch's Qt platform plugin:QTimer::startis called from alibmir1clientdispatch thread. origin/main, built the same way and installed on the same phone, logs it on every launch too. I checked 3 of 3 journal windows (without my handler). The PR's build logged it on 4 of 4 launches, 5 of 5 counting the clean reinstall.Fix: none in our code, and I did not silence the warning. My earlier note that main does not log it was wrong. The e2e harness runs under Xvfb, which has no Mir, so no case can see it (0 hits in the restore and starter-install app logs). I added no case, and the head stays
7e757bd.The PR body's Phone section is updated with this.
Level: medium (delta review, trunk blast radius)
Commit:
7e757bd8e7Range: 7e757bd8e739192a05109039f9dba805b459fa2b..7e757bd (empty: no code change)
Files: none changed. Checked qt/, qml/ for QTimer, startTimer, qInstallMessageHandler and backtrace: no matches, so the debug handler is not in the tree and no PR code starts a timer.
Findings: none.
The "fix" is a diagnosis with no code change. A QTimer started from a Mir client dispatch thread inside libqpa-ubuntumirclient is outside this repo, and the author reports the same warning on the unmodified main build. Nothing here introduces thread-affinity, blocking-GUI or ordering risk, and no proof depends on a code change. I could not reproduce the phone logs from this environment, so the backtrace and the main-build observation are taken from the author's report.
WIP: First run: starter-set picker and background installs (#10 part 2a)to First run: starter-set picker and background installs (#10 part 2a)Merge gate (step 8) on head
7e757bd8e7: APPROVED.7e757bd; PR is mergeable; no commit after the last review round (245 ondff31c6, re-review 246 on dff31c6..7e757bd, delta 247 empty range).7e757bd(each checked by review 246) and the 6th (docs/07 effect) is answered in the body.Weaker spots the author already states, not blocking: the review-245 fix tests use new APIs and were never run against the old code, and the starter-over-the-picker fix has no failing-before proof or e2e case (it is on the owner's phone checklist). Merge with head pinned and the Review-Confidence and Review-Tier trailers ending the message.