Skip to content

fix(gui): stop offering in-app updates where no artifact ships - #838

Open
4ni1ak wants to merge 3 commits into
AprilNEA:masterfrom
4ni1ak:fix/linux-package-managed-updates
Open

fix(gui): stop offering in-app updates where no artifact ships#838
4ni1ak wants to merge 3 commits into
AprilNEA:masterfrom
4ni1ak:fix/linux-package-managed-updates

Conversation

@4ni1ak

@4ni1ak 4ni1ak commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

Summary

Settings → Updates offered a check that can only fail on Linux.

Split out of #802 at your request.

Fixes #769

Changes

A Linux release publishes distro packages only — .deb, .rpm,
.pkg.tar.zst — and xtask release latest-json deliberately classifies none of
them into the update manifest, because those installs update through the package
manager. The GUI asked anyway, so opening Settings → Updates and clicking Check
produced a red "Update failed: no release asset matched the current platform
(linux/x86_64)".

  • One IN_APP_UPDATES const in platform::updater states whether this build has
    an in-place-updatable artifact at all.
  • The launch-time check, the auto-install observer and check_for_updates skip
    the check where it does not. The menu item stays and still opens the page,
    which now explains where updates come from.
  • The Updates page shows the running version and the update source instead of a
    check button and two switches that cannot do anything.
  • macOS and Windows are unchanged.

The one new string is added to every shipped catalog at the same position.

Testing

Linux, x86_64, Rust 1.98.0:

cargo test -p openlogi-ui locale     # catalog parity
cargo test -p openlogi-desktop i18n  # key resolution
cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings   # RUSTFLAGS=-D warnings
cargo test --workspace

All green.

Not run on this host: tests (macos), cargo-deny, macOS clippy (no macOS
SDK here). The macOS and Windows paths are unchanged by construction —
IN_APP_UPDATES is true there and every branch behaves as before — but that
is an argument, not a test run.

Not runtime-tested. To verify: open Settings → Updates on a Linux install
and confirm it states the package manager rather than offering a check; on macOS
confirm the check still runs and reports normally.

Note on ordering: this adds a string to every catalog that exists today. If
the Turkish locale PR lands first, this branch needs a rebase so tr.yml gets
the same key before the parity test passes — happy to rebase whenever it suits
you, and the same the other way round.

@greptile-apps

greptile-apps Bot commented Aug 23, 2026

Copy link
Copy Markdown

Greptile Summary

This PR prevents unsupported platforms from offering in-app update operations while preserving the existing macOS and Windows behavior.

  • Centralizes platform support in IN_APP_UPDATES.
  • Gates startup, consent, automatic installation, and manual update checks.
  • Replaces Linux update controls with package-manager guidance and localized explanatory text.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported Linux consent bypass is now gated both where the prompt opens and where consent triggers the check.

Important Files Changed

Filename Overview
crates/openlogi-desktop/src/platform/updater.rs Defines the shared platform capability and consistently gates startup checks and automatic installation.
crates/openlogi-desktop/src/windows/update_consent.rs Completes the prior consent-path fix by preventing accepted consent from invoking the updater on unsupported platforms.
crates/openlogi-desktop/src/windows/settings/updates.rs Replaces unusable updater controls with a package-managed update explanation when in-app artifacts do not ship.
crates/openlogi-desktop/src/app/menu.rs Makes manual update actions platform-aware while continuing to open the Updates page.
crates/openlogi-desktop/src/runtime.rs Suppresses the first-run update-consent prompt on platforms without in-app update artifacts.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Open update entry point] --> B{IN_APP_UPDATES?}
    B -->|Yes| C[Use in-app updater]
    B -->|No| D[Open package-managed Updates page]
    C --> E[Check, download, and install]
    D --> F[Show installed version and releases link]
Loading

Reviews (5): Last reviewed commit: "fix(gui): stop describing how OpenLogi w..." | Re-trigger Greptile

Comment thread crates/openlogi-desktop/src/platform/updater.rs Outdated

@AprilNEA AprilNEA left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core Linux updater gating is sound and covers the startup, automatic, manual, Settings, and consent paths. The new Linux-facing UI still makes contradictory and incorrect claims about how the current installation is updated; please address the inline comments before merging. Also change the closing reference from Fixes #769 to Fixes #605, because #769 is already closed as a duplicate and the open tracking issue would otherwise remain open. Per the project UI review requirements, please add a Linux runtime check and screenshot of the resulting Updates page.

.child(concat!("OpenLogi ", env!("CARGO_PKG_VERSION"))),
)
.child(div().text_caption().text_color(pal.text_muted).child(tr!(
"Installed from a distribution package — updates come from your package manager."

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Do not infer the installation method from target_os. This branch runs for every Linux build, including the source-build path documented in docs/INSTALL-linux.md and reported in #605, yet it tells all of them they were installed from a distribution package. The official .deb/.rpm instructions also download artifacts manually and configure no package repository, so a package manager will not discover future releases on its own. Please use installation-neutral copy such as ‘In-app updates are unavailable on Linux; update using the method you installed OpenLogi with,’ or detect the actual install source.

.icon(IconName::ArrowDown)
.resettable(false)
.group(hero)
.group(SettingGroup::new().item(SettingItem::render(move |_, _, _| update_source(pal))))

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Avoid reusing the updater-enabled source footer here. On this new Linux page, update_source still labels GitHub Releases as the update source and says OpenLogi connects when automatic checks are enabled or Check for Updates is clicked, even though this PR removes those controls and suppresses every check. Render a source/footer variant for this page so it presents one consistent update path.

// packages only), running the check just resolves to "no release asset
// matched the current platform". Open the Updates page anyway — it says
// where updates come from on this install.
if crate::platform::updater::IN_APP_UPDATES

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] This deliberately skips the check on Linux, but the invoking menu item remains ‘Check for Updates…’ and the deeplink/command contract still says it runs a check. A Linux user selecting it gets navigation only. Please rename or hide this action on unsupported platforms, or give it platform-neutral ‘Updates…’ semantics.

/// resolves to "no release asset matched the current platform", which reads as
/// a failure rather than as the design it is, so Linux skips the check and the
/// Updates page says where updates actually come from.
pub const IN_APP_UPDATES: bool = !cfg!(target_os = "linux");

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P3] Make this capability fail closed. The static manifest only ships in-app artifacts for macOS and Windows, but !cfg!(target_os = "linux") enables every other current or future target and recreates the same NoMatchingAsset failure there. Prefer a positive macOS/Windows predicate.

@4ni1ak
4ni1ak force-pushed the fix/linux-package-managed-updates branch from 666a08c to 4f7e9f4 Compare August 24, 2026 19:20
@davidbudnick davidbudnick added type: bug Something is broken or behaves incorrectly area: gui Graphical user interface labels Aug 25, 2026
4ni1ak added 3 commits August 25, 2026 17:27
A Linux release publishes distro packages only — `.deb`, `.rpm`,
`.pkg.tar.zst` — and `xtask release latest-json` deliberately classifies
none of them into the update manifest, because those installs update
through the package manager. The GUI asked anyway, so every Linux user who
opened Settings → Updates and clicked Check got a red "Update failed:
no release asset matched the current platform (linux/x86_64)".

Gate the updater on a single `IN_APP_UPDATES` const: the launch check, the
auto-install observer, and the menu action skip the check where a release
carries no in-place-updatable artifact, and the Updates page shows the
running version plus where updates come from instead of a check button and
two switches that cannot do anything. macOS and Windows are unchanged.

The new string is added to every shipped catalog at the same position.

Fixes AprilNEA#769
The consent window asks whether to turn the update check on, and its
"Enable" handler ran one check immediately without consulting
`IN_APP_UPDATES` — so a first-run Linux user still reached the asset lookup
and its "no release asset matched the current platform" failure, one dialog
before the Updates page that now avoids exactly that.

Skip the window entirely where a release ships no in-place-updatable
artifact: offering to enable a check whose every outcome is that failure is
the same defect one layer up. The handler keeps its own gate as well, since
it is reachable from the window whenever the window is.

Found by the Greptile review on this PR.
Four review findings on this PR:

The capability was `!cfg!(target_os = "linux")`, which enables every target
that is not Linux — including any added later, which would inherit the same
"no release asset matched the current platform" failure without anyone
choosing it. `xtask release latest-json` classifies exactly two artifacts, so
name those: `cfg!(any(target_os = "macos", target_os = "windows"))`.

The page told every Linux build it came from a distribution package. It
cannot know that: source builds follow `docs/INSTALL-linux.md`, and the
official `.deb`/`.rpm` route is a manual download that configures no
repository, so no package manager will find the next release for those
either. Say only what is true — in-app updates are unavailable here, update
the way you installed it.

It also reused `update_source`, which calls GitHub Releases the *update
source* and explains when OpenLogi connects for automatic checks or a manual
Check for Updates — controls this page removes. It gets its own footer:
the link is where to read the changelog, and the one outbound request named
is the one opening that page makes.

Finally the menu item still read "Check for Updates…" while only navigating.
It reads "Updates…" where no check can run.

Found in review by @AprilNEA.
@4ni1ak
4ni1ak force-pushed the fix/linux-package-managed-updates branch from 09e77f2 to 104f790 Compare August 25, 2026 14:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: gui Graphical user interface type: bug Something is broken or behaves incorrectly

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: "Update failed: no release asset matched the current platform (linux/x86_64)"

3 participants