[hussainph]

Fixes VC-851 (split from VC-705; the VC-684 item that was folded into it).

Problem

• readAllowPrerelease read an absent volli:update-allow-prerelease row as false, and readUpdateChannel mapped that to "stable". electron-updater's own default on a prerelease version is allowPrerelease = true, so on a fresh canary install Settings → Updates and the support report said Stable while the install was following the canary feed.
• startAutoUpdate only ever assigned allowPrerelease = true. Choosing Stable on a canary build wrote false and the select showed Stable, but that false was never applied. The canary build's updater kept true and, because electron-updater's GitHub provider only picks canary-tagged releases for a -canary current version, kept taking canaries indefinitely.

Fix

• The choice now has three states: readAllowPrerelease returns true, false or null (never chosen). An absent row, or anything other than an exact JSON boolean ("1", malformed JSON), reads as null.
• readUpdateChannel(db, buildKind) returns the effective line: the explicit choice if there is one, otherwise the running build's line (runningBuildKind). A canary build reads Canary; stable and dev builds read Stable. volli:update-channel-get and the support report both read it, so they agree. SupportInfoDeps gains buildKind.
• At launch, startAutoUpdate applies an explicit choice either way (updater.allowPrerelease = choice). null leaves electron-updater's version-derived default alone, as before. The startup log line says toggle=unset for that case.
• Settings → Updates: after someone switches from Canary to Stable, the pane shows a notice: "Stable takes effect the next time Volli opens. An installed canary build stays until a newer stable release is out." (The row hint and the enter-canary confirm already say an installed canary won't downgrade.)

Unchanged: the updater's phases, download and install flow (VC-24/VC-59/VC-111), the feed, and the IPC contract.

Decisions

• Stable is honoured at the next launch, not live. If the running updater were narrowed mid-run, a re-check with a canary already staged would come back update-not-available and drop the pane's downloaded phase, which is the phase logic this ticket must not touch. So the stored false is assigned at the next startup, and the pane says that's when it takes effect. Entering Canary still widens the running updater straight away, as before.
• Forcing false on a canary build is safe now. The old one-way rule existed because the stable-only feed (releases/latest) 404'd while only prereleases existed. Full releases ship now (v0.2.2 is Latest). A canary build told Stable reads releases/latest, sees an older stable, stays put (allowDowngrade is false), and moves onto the first stable release newer than it. I checked this against electron-updater 6.8's GitHubProvider.getLatestVersion and AppUpdater.isUpdateAvailable.
• Malformed rows read as "never chosen", not as false. On stable builds the result is the same as before (the default is false, so a corrupt row still can't widen anything). On canary builds it matches what the updater was already doing.
• The select shows the stored choice, not the live updater flag. Right after leaving Canary the live flag is still true until relaunch. Reading it would snap the select back to Canary, and the notice already explains the gap.

Tests

• src/main/auto-update.test.ts: covers readAllowPrerelease in three states, readUpdateChannel for a never-chosen canary/stable/dev build, an explicit choice overriding the build, a malformed row, exact JSON true/false writes, and startup honouring an explicit Stable on a canary build while leaving the default alone when nothing was chosen. 8 of these fail on main (run against the unchanged source): the fresh-canary case gets expected 'stable' to be 'canary', and explicit-Stable-on-canary gets expected true to be false.
• src/main/support-info.test.ts: the report says canary for a never-chosen canary build, stable for a stable build, and stable for an explicit Stable on a canary build.
• src/renderer/.../updates-pane.test.tsx: switching from Canary to Stable shows the next-launch notice.
• Run locally, one file at a time with --maxWorkers=1: auto-update 49/49, support-info 15/15, updates-pane 9/9. vp check passes on the 8 touched files.
• Overlap: git merge-tree is clean against origin/main and the heads of VC-834: background Change Set/rail/venue/diff reads run read-only git (stacked on #885 — merge after it) #909, VC-838: refuse one-click commit over unmerged index entries #919, VC-796: host-owned project.remove stops a project's live work before its delete #920, VC-807: confirm a minted harness launch before it moves the resume seed; skip announce for --version/--help/housekeeping and nested runs #921 and VC-831: release page-scoped sign-ins and file/dir/worktree watches when the renderer page reloads or crashes #922.

Follow-ups (from review, not fixed here)

• The leaving-canary notice only lives in component state. It disappears when the pane remounts. After relaunch, nothing explains a canary "Current version" sitting under Stable. On a stable build the "installed canary stays" line can show when no canary is installed. Derive it from main later, by comparing the stored choice with the build kind.
• The support report says stable between choosing Stable and the relaunch, while the live updater is still taking canaries (by design here, since leaving is applied at the next launch).

CI note

First run: Smoke (shard 3/3) failed only in browser-page-navigation-smoke.mjs (enter/button: generation=1->1), which is the known flake VC-779. Every other check passed. I reran the failed jobs once (run 39242197547).

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 92a19c28-f986-4276-b126-a61b815af2f2

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}