A failed profile install is classified but not rolled back — the profile keeps the residue and can fail the same way forever

[Ragnoryok1]

Summary. runProfilePnpm reads the profile manifest before running pnpm, but that snapshot is used only on success (to reconcile newly activated bundles). On a non-zero exit it returns the classified failure — the taxonomy in install-failure.ts is good — and nothing else: no manifest restore, and no cleanup of pnpm's staging directories. Nothing detects the residue on later runs, so the next install can fail identically.

Where

• packages/boot/plugin-manager/src/operations.ts:105-164 — before read at :109; used only in reconcile(...) under exitCode === 0 at :160; plain return at :164.
• restoreManifest / rollback / revert do not appear anywhere in the package (searched).

Evidence from my machine. The web profile accumulated 36 _tmp_<pid>_<n> staging directories from six failed attempts. pnpm install then failed repeatedly with [ERR_PNPM_EPERM] [importPackage ...\node_modules\dsh-mobile-host] EPERM: operation not permitted, rename '...\dsh-mobile-host_tmp_7568_10' -> '...\dsh-mobile-host' — including with the server stopped, i.e. not a file-lock story: pnpm's bookkeeping never settled, so every run tried to re-import the same file: dependency over the existing directory. Installing an unrelated plugin through the same path hit it too. Recovery was manual: park the target directory aside, let the install run to completion, restore it. The staging residue that survived those attempts I had to delete by hand.

Suggested directions

1. Restore the manifest snapshot on failure — the value is already read for the success path.
2. Remove _tmp_* staging directories in a finally, and detect pre-existing ones before starting a run (a single detection makes the "poisoned profile" state visible instead of chronic).
3. Separate "resolution failed" from "import failed": the first should revert the manifest edit, the second should also clear staging.
4. Include the residue path in the failure message so the user can act without reading the code.

Question. Is the manifest intentionally left modified on failure so a retry can resume? And is the _tmp_* residue expected to be cleaned by a later successful run? On my machine it was not, and the later runs failed the same way.

[Ragnoryok1]

A fresh reproduction on 0.1.7-rc.2, from an ordinary operation rather than a failed experiment — updating my own published plugin in the profile:

• dsh plugin --profile web update @ragnoryok1/dsh-client-locale-ru@0.1.6 resolved and downloaded the version, staged it, and failed on the final rename: [ERR_PNPM_EPERM] [importPackage …\node_modules\@ragnoryok1\dsh-client-locale-ru] EPERM: operation not permitted, rename '…\dsh-client-locale-ru_tmp_11860_3' -> '…\dsh-client-locale-ru' — the running host holds the package directory.
• Nothing rolled back: the profile manifest stayed at ^0.1.4, and the _tmp_11860_3 staging directory remained in node_modules until I deleted it by hand. The diagnostics path in the failure message is the part that works well.
• The update only completed once the installed directory was parked aside so the rename had no target; with the server stopped the plain command succeeds. That is the same workaround the earlier 36-_tmp_ case needed.

So the defect reproduces on demand from a single ordinary operation, not only after repeated failures, and leaves the same residue every time. The invariants in the report stay the ones to fix: restore the manifest on failure, clear _tmp_* in a finally, and detect pre-existing staging directories before starting.