[bug] two MSI installers (multiple WiX languages) collapse into one key in latest.json

Open
  • Is something wrong?
#3,777 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, rust
Domain
backend, release

Research direction

Find the updater plugin code that assembles latest.json entries for Windows bundle artifacts, then trace how MSI filenames and architectures become manifest keys. Compare the generated keys for a build with wix.language set to en-US and ru-RU. Done means both MSI languages can be selected distinctly, or the build reports the documented limitation without silently overwriting an entry.

Written by the indexing model from the issue text.

Description

platform: windows plugin: updater type: bug type: feature request
Describe the bug

When bundle.windows.wix.language lists more than one language, both MSIs are built and
attached to the release correctly, but the updater manifest ends up with only one MSI entry
per architecture. The second language overwrites the first.

I build a Tauri v2 app (tauri 2.12.5, tauri-cli 2.12.4, tauri-plugin-updater 2.14.1) for
Windows, Linux and macOS in one GitHub Actions workflow. Each platform job runs
tauri build and the three resulting latest.json files are merged into one, so I can see
exactly which keys each platform produced.

The Windows job produced this:

windows-x86_64       -> StackerPulse_3.2.1_x64_en-US.msi
windows-x86_64-msi   -> StackerPulse_3.2.1_x64_ru-RU.msi
windows-x86_64-nsis  -> StackerPulse_3.2.1_x64-setup.exe

Both MSIs exist and are signed. There is no key that distinguishes them by language, so
windows-x86_64-msi holds the ru-RU build while windows-x86_64 holds the en-US one — two
keys for the same architecture pointing at different languages, and no way to ask for a
specific one.

Reproduction

Real case with both installers and the manifest attached:
https://github.com/UBro-dev/stacker-pulse/releases/tag/v3.2.1

Steps:

  1. Tauri v2 app with msi in bundle.targets:

    "bundle": {
  "targets": ["deb", "appimage", "msi", "nsis", "app"],
  "windows": {
    "wix": { "language": ["en-US", "ru-RU"] },
    "nsis": { "languages": ["English", "Russian"], "displayLanguageSelector": false }
  }
}

  2. Enable the updater and build on Windows.

  3. Inspect the generated latest.json: there is one windows-x86_64-msi key, and it points
    at whichever MSI was processed last — in my case ru-RU — while windows-x86_64 points at
    the en-US MSI.

Both MSIs are built and uploaded, so this is not a bundling failure.

Expected behavior

One of:

  • a distinct key per language, e.g. windows-x86_64-msi-en-US and windows-x86_64-msi-ru-RU,
    so a client can request the right build; or
  • if multiple MSI languages cannot be expressed in the manifest, a warning at build time and
    a documented rule for which one wins, instead of silently replacing the previous entry.

Right now the manifest is correct enough to pass any asset check — all files are present and
signed — while still directing some users to the wrong-language installer.

Full tauri info output
[✔] Environment
    - OS: Windows 10.0.26200 x86_64 (X64)
    ✔ WebView2: 157.0.4341.42
    ✔ MSVC:
        - Visual Studio Build Tools 2022
        - Visual Studio Build Tools 2026
    ✔ rustc: 1.97.1 (8bab26f4f 2026-07-14)
    ✔ cargo: 1.97.1 (c980f4866 2026-06-30)
    ✔ rustup: 1.29.0 (28d1352db 2026-03-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 24.19.0
    - npm: 11.17.0
    - bun: 1.4.4

[-] Packages
    - tauri 🦀: 2.12.5
    - tauri-build 🦀: 2.7.4
    - wry 🦀: 0.57.1
    - tao 🦀: 0.37.2

[-] Plugins
    - tauri-plugin-updater 🦀: 2.14.1

[-] App
    - build-type: bundle
    - CSP: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src ipc: http://ipc.localhost; object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
    - frontendDist: ../ui
Stack trace
N/A — the build succeeds; the problem is in the generated updater manifest.
Additional context

Two side notes that may help narrow it down:

  1. The collision only involves MSI. NSIS has its own single key (windows-x86_64-nsis) and
    the .exe embeds the language selector, so nothing is lost there. The problem is specific
    to producing two MSI files for one architecture.

  2. This is easy to miss in CI. My workflow verifies that every platform has a signed entry in
    latest.json and that all links are pinned to the tag — that check passes, because the
    entries exist. Only comparing the MSI keys against the MSIs actually attached reveals it.
    A user on an MSI install would silently receive the other language after an update.

Previously I filed tauri-apps/tauri#16460 about universal macOS builds with more than one [[bin]]; this is a
separate issue found while verifying the 3.2.1 release.

Dominant language
Rust
Stars
1.8k
Forks
637
Avg merge
5d 3h
Merged PRs (30d)
36

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tauri-apps/plugins-workspace

All issues in tauri-apps/plugins-workspace

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.