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

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

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

Research direction

Start by tracing how Windows MSI bundle artifacts are named and inserted into latest.json; the issue identifies bundle.windows.wix.language as the trigger. Compare the manifest keys with the two generated MSI filenames for each architecture. Done means each language has a distinguishable manifest entry, or the build warns and documents which MSI is selected.

Written by the indexing model from the issue text.

Description

status: needs triage type: bug
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 #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
113k
Forks
4.2k
Avg merge
2d 8h
Merged PRs (30d)
82

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

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/tauri

All issues in tauri-apps/tauri

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.