Skip to content

fix(market): label installed MiniApps with their marketplace release - #1934

Merged
bobleer merged 1 commit into
GCWing:mainfrom
bobleer:bob/bitfun-app-version-display-d12426
Jul 31, 2026
Merged

fix(market): label installed MiniApps with their marketplace release#1934
bobleer merged 1 commit into
GCWing:mainfrom
bobleer:bob/bitfun-app-version-display-d12426

Conversation

@bobleer

@bobleer bobleer commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

Problem

Two issues reported against the MiniApp marketplace:

  1. A listing with several releases shows every release in 版本历史 as an equally current row.
  2. After installing a listing whose latest release is v2, the installed app card still reads v1, which looks like the install fetched an older package.

Diagnosis

The second one is a labeling bug, not a wrong download.

  • The client installs detail.latestRelease and downloads /listings/{slug}/releases/{n}/download; the server resolves that row by release_number, and the desktop side rejects the package unless its sha256, size, and permissions match the reviewed release (miniapp_market_api.rs). The v2 package really is what lands on disk.
  • The card renders v{app.version}, and app.version is the local edit counter. build_created_app hardcodes it to 1, and install_strict_package deliberately discards the package's own version — the marketplace release number lives in the customization metadata's market origin and is documented as independent from the local counter.

So a fresh install of any release always displayed v1.

Changes

  • New miniapp_market_installed_origins command returning each installed app's marketplace origin keyed by app id (LocalOnly remote-workspace policy, registered in generate_handler!). miniapp_market_installed_status now shares its metadata lookup.
  • miniAppStore tracks those origins, loaded alongside the catalog in useMiniAppCatalogSync and the gallery refetch, and recorded directly after a market install. A failed origins read degrades the labels to the local counter instead of taking the catalog down.
  • MiniAppCard and the gallery detail modal show the marketplace release number when the app came from the marketplace; other apps keep the local counter.
  • The listing detail's version history collapses to the newest release, with a toggle for the older ones (buildReleaseHistory, sorted newest-first so it does not depend on server ordering).
  • New i18n strings for en-US / zh-CN / zh-TW.

Testing

  • vitest run src/app/scenes/miniapps — 15 files, 51 tests pass (includes new miniAppReleaseHistory cases and store coverage for origin pruning)
  • tsc --noEmit on web-ui
  • eslint on the touched web-ui paths
  • cargo clippy -p bitfun-desktop --all-targets — no new warnings
  • cargo test -p bitfun-desktop --lib remote_workspace_policy — 7 pass
  • pnpm run i18n:audit — 0 warnings

An installed MiniApp card showed `v{app.version}`, but that counter is the
local edit counter, which `build_created_app` always starts at 1. Installing
release v2 from the marketplace therefore rendered as "v1", reading as if the
install had silently fetched an older release. The download itself was correct:
the client requests `/listings/{slug}/releases/{n}/download` for the listing's
latest release and rejects any package whose sha256, size, or permissions do
not match the reviewed release.

Add `miniapp_market_installed_origins`, which returns the marketplace origin of
every installed app, and let the gallery label market-installed apps with the
release number they actually carry. Apps from anywhere else keep the local
counter.

Also collapse the listing detail's version history to the newest release, with
a toggle for the older ones, so a listing with several releases no longer
presents them as equally current.
@bobleer
bobleer merged commit 3479576 into GCWing:main Jul 31, 2026
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant