[Bug][0.2.2-alpha.2] Failed rollback activation is reported as “plugin is not installed”; the suggested Add action then returns already-installed

[kapelame]

When a third-party bundle update fails, the official Plugins → Versions dialog can tell the user that the plugin is not installed and to install it again from Add plugin, even though the previous version was successfully reinstalled and only its activation failed. Following that instruction is refused with already-installed.

Version and verification scope

• dsh-v0.2.2-alpha.2, commit f3803c96974ad4a94195fb97e5c637e9c2a3afe3; macOS arm64, Node v26.10.0.
• This report concerns the official third-party Versions/update dialog. It is not a report about a third-party market's separate updater. The latest rc.5 tag does not contain this versions.tsx UI.
• The affected versions.tsx is byte-identical on current master ce7073d51254c26cd63b22a60835b8f948deb447.
• Reproduced with the release's original PluginManager source, its real profile/Loader/HMR fixture, and the original UpdateDialog and locale source. runProfilePnpm and registry answers were stubbed to create temporary package files and inject a target download failure. The Loader actually executes the fixture plugin and reports its activation error. React SSR used substitutes for visual primitives and unused discovery helpers. This is focused source/runtime verification, not a real registry download or a full Desktop/GUI test. No model calls or real user profiles were used.

Minimal scenario

1. Start an HMR-enabled temporary profile with a working registry bundle extra@1.0.0.
2. Make a resource that the bundle needs on startup unavailable. In the fixture, the unchanged plugin's apply() checks a temporary sentinel file and throws fixture external resource unavailable while it exists. The initially running plugin, reinstalled plugin bytes, and bundle patch are otherwise identical.
3. Call pluginManager.updateBundle('extra', '1.2.0'). The package-operation fixture makes the target download fail after removing 1.0.0, then successfully reinstalls 1.0.0. Activating that restored version fails because the resource remains unavailable.
4. Pass the actual Host answer into the original finished UpdateDialog.
5. Follow its suggestion by calling installBundle('extra@1.0.0').

The relevant actual Host answer is:

{
  "from": "1.0.0",
  "to": "1.2.0",
  "step": "install",
  "result": {
    "stage": "install",
    "application": "failed",
    "packageResult": { "exitCode": 1 }
  },
  "restore": {
    "stage": "enable",
    "application": "failed",
    "changed": true,
    "bundle": "extra",
    "version": "1.0.0",
    "packageResult": { "exitCode": 0 },
    "error": {
      "code": "operation-error",
      "diagnostic": "dsh: warning: 1 entry did not activate ... Error: fixture external resource unavailable"
    }
  }
}

At this point:

• package.json.dependencies.extra is 1.0.0.
• listBundles() reports {name: 'extra', version: '1.0.0', installed: true, enabled: true}. Here enabled is the saved selection, not successful activation.
• The dialog says “Update failed; the plugin is not installed”. Its detail treats both the target and fallback as installation failures and tells the user to reinstall from Add plugin. The Chinese locale has the same behavior.
• The suggested installBundle('extra@1.0.0') returns application: 'failed', error: {code: 'already-installed'}.

Expected result

Distinguish a missing/uninstalled fallback from an installed fallback that could not activate. In this case, retain the fact that 1.0.0 is installed, show its activation diagnostic, and suggest fixing the activation problem and retrying activation, rather than Add plugin. Reserve “not installed” for an outcome that actually proves absence.

The original outcomeOf() currently classifies solely by failed(result.restore.application) and maps every failed restore to updateBroken/updateBrokenDetail, without accounting for a successful package installation followed by stage: 'enable' failure:

• Outcome classification at the alpha.2 release
• English recovery text

Verification and workaround

• Failed-activation scenario: 3/3 isolated Host runs reproduced the installed state and already-installed refusal.
• Original dialog SSR: English and Chinese reproduced the incorrect statement.
• Control: a failed target download followed by successful fallback activation reported “restored 1.0.0” correctly in both locales.
• After making the fixture resource available, turning the bundle Off then On successfully activated it and restored its provided service. No reinstall was needed. Simply calling enable while it was already selected did not reload the failed entry in this fixture.

The Host behavior of retaining a successful package installation after activation failure is documented and is not the behavior I am asking to change; this is a mismatch in the update dialog's diagnosis and recovery instruction. I found related reports about market updaters calling installBundle over already-installed packages (e.g. #11250 and #10299), but those fail before pnpm and do not cover this fallback-activation result. I searched the accessible open/closed feedback and current source and the history of versions.tsx; GitHub's PR-list endpoint returned 404 for this repository, so I could not rule out an inaccessible internal PR.

This report was prepared with AI assistance. All stated test results come from actual isolated runs, with the fixture and UI-rendering boundaries described above.

[PedroCostinha]

Hi! I think the rollback workflow would benefit from distinguishing package installation from plugin activation.

A restored package can exist on disk while its activation fails. Reporting that state as "not installed" makes recovery confusing, especially if reinstalling then reports that the package already exists.

I would suggest representing these as separate states: package restored, activation pending, activation failed, and plugin active.

The recovery action could then retry activation or display the underlying activation error without unnecessarily reinstalling the package.

A regression test should cover a successful rollback followed by an activation failure and verify that the UI reports the actual state consistently.

[zuwenyin]

I hit exactly this classification problem in a third-party version manager (dsh-plugin-upgrader), so here is the caller-side view — including the fact that our own rollback path has the same defect you describe, which your report made me go and check.

The distinguishing signal is already in the ChangeResult

The Host answer you pasted is enough to tell the two situations apart without any new Host API:

"restore": {
  "stage": "enable",
  "application": "failed",
  "changed": true,
  "packageResult": { "exitCode": 0 },
  "error": { "code": "operation-error",
             "diagnostic": "dsh: warning: 1 entry did not activate ..." }
}

• packageResult.exitCode === 0 and changed === true → pnpm ran and the package is on disk.
• stage === 'enable' → it got as far as activation.
• application === 'failed' + error.code === 'operation-error' → activation is what failed.

So "package restored, activation failed" is exitCode === 0 && changed === true && stage === 'enable'. "Package gone" is exitCode !== 0 || changed === false. outcomeOf() classifying solely on failed(result.restore.application) throws that away, which is why a successful reinstall collapses into updateBroken.

Our bug, for the record

dsh-plugin-upgrader re-installs the previous version itself when a replacement destroys it (src/host/install.ts:414, rollBack()). It decides success like this:

const result = await manager.installBundle(spec, { ...options, requestId })
const back = result?.application === 'applied' || result?.application === 'restart-required'
if (result?.error !== undefined || !back) {
  log(`  ! rollback refused (${result?.error?.code ?? 'no change'}); ` +
      `${step.name}@${previous} is not installed — ` +
      'install it again from the Installed tab')
  return false
}

If activation fails after a clean reinstall, application is 'failed', so we fall into that branch and print "is not installed" for a package that is installed — the same wrong diagnosis, one layer down, and with the same useless advice ("install it again") that the Host then refuses with already-installed. Your report is about versions.tsx; the failure mode is not specific to it.

The fix on our side is to read the three signals rather than one, and to stop calling the reinstall a failure when the only failing part is activation:

• exitCode !== 0 || changed === false → not installed, tell the user to install it again (this is the only case where that advice is true);
• stage === 'enable' && application === 'failed' → installed, not activated: keep rolledBack: previous, surface error.diagnostic, and offer "retry activation" instead of "reinstall";
• application === 'applied' || 'restart-required' → fully back.

Retrying activation: do not go through installBundle

Worth stating explicitly because it is the trap your "Add plugin" suggestion walks into: once the dependency is back in package.json.dependencies, installBundle(spec) is refused with already-installed before pnpm is even reached, so it can never be the retry path for an activation failure.

What works, and matches your "turning the bundle Off then On successfully activated it": toggle the bundle off and back on (setBundleEnabled(false) then setBundleEnabled(true)), which makes the loader actually release and re-evaluate the fiber. Calling enable while the bundle is still selected does nothing, because the saved selection never changed — listBundles().enabled is the selection, not a record of successful activation, exactly as you noted.

Suggested shape for the dialog

Two independent questions, two answers:

question	source	wording
is the package there?	packageResult.exitCode, changed	"1.0.0 is installed" / "could not restore 1.0.0 — install it again"
is it running?	stage, application, error.diagnostic	"but it did not activate: <diagnostic>" + a retry-activation action

"Not installed" then becomes reachable only when the package really is absent, and the Add-plugin suggestion is never offered for a package that is on disk. A regression covering "rollback installs the old version successfully, activation of the restored version fails" and asserting the restored-and-installed wording would pin it — that is the case where the current string is provably wrong.

(The comment is from the author of dsh-plugin-upgrader, which ships the same defect described above; I am not linking it as a solution, only as a second implementation that ran into the identical taxonomy problem.)

[zuwenyin]

Thanks — this report found a real bug in a third-party plugin too, so I fixed mine and shipped it, rather than only commenting.

My plugin had the same flaw. My rollBack() treated "the install did not report success" as "the package is not installed", and printed exactly the sentence you are complaining about:

! rollback refused (operation-error); pkg@1.0.0 is not installed — install it again from the Installed tab

Then the user goes to the Installed tab, hits install, and gets already-installed. Same dead end you hit in UpdateDialog.

The signal was already there

ChangeResult carries enough to tell the three outcomes apart without any new host API:

what happened	changed	stage	packageResult.exitCode	application
old version is back and running	true	enable	0	applied / restart-required
old version is on disk but not active	true	enable	0	failed
old version was never put back	false / no result	—	non-zero	failed

My predicate is the middle row:

function landedOnDisk(result: ChangeResult | undefined): boolean {
  if (result === undefined || result.changed !== true) return false
  if (result.stage !== 'enable') return false
  const exit = result.packageResult?.exitCode
  return exit === undefined || exit === 0
}

Three signals, all required. changed says the profile was rewritten, packageResult.exitCode says pnpm itself succeeded, stage says how far the host got. Stopped at enable with a clean pnpm means the bytes are on disk and the fiber did not come up.

One caveat: application alone is not enough. A failed result with changed: true and a non-zero exit code means pnpm died and the old version is not there either — that one really does need a reinstall. That is why the exit code has to be part of the check.

What I changed

rollBack() now returns a three-way outcome instead of a boolean:

type Rollback =
  | { kind: 'back' }                        // old version back and running
  | { kind: 'inactive'; reason: string }    // on disk, host could not activate it
  | { kind: 'refused';  reason: string }    // really not there

inactive produces a different sentence and a different instruction:

! pkg@1.0.0 is installed but did not activate (dsh: warning: 1 entry did not activate);
  the package is back on disk - enable it again from the Installed tab

Only refused still says "is not installed — install it again". The panel shows them as separate lines too, because "go re-enable it" and "go reinstall it" are different actions for the user.

Two things worth keeping in mind for the host fix

Do not retry activation through installBundle. The dependency is already declared, so the retry gets already-installed — the exact path your reporter fell into. The path that actually re-runs activation is setBundleEnabled(false) then setBundleEnabled(true). My removeForReplacement has been using that for the bundle-in-use case since 1.6.x, and it works for reactivation for the same reason: it makes the loader actually let go and then re-evaluate.

listBundles().enabled is not evidence that it is running. It reports the user's selection, not the fiber. In your report listBundles() returned { installed: true, enabled: true } while the entry had failed to activate — that pair is not a contradiction, it is the whole bug. Any state machine the dialog uses needs the fiber phase for "running" and the selection for "off", kept apart.

Published and reproducible

dsh-plugin-upgrader@1.7.5 is on npm and as a GitHub Release (commit 9f1d069). Regression: a rollback that installs but cannot activate is not called "not installed" (plus the existing refused case now asserts inactive === undefined). Sentinel check: forcing landedOnDisk to false — the 1.7.4 behaviour — turns exactly that one test red, and it goes green again when reverted.

Write-up with the full chain: docs/rules/24-rollback-inactive.md.

So from the outside: your distinction between "package restored", "activation pending", "activation failed" and "plugin running" is exactly right, and it is expressible today with changed + stage + packageResult.exitCode. The dialog just needs to ask the two questions separately — is the package there, and is it running — instead of collapsing both into "installed".