Repository navigation
Replies: 5 comments 1 reply
Follow-up: the same failure recurred a day later, and the operation log still loses pnpm's outputUpgrading on the same
On this profile the bypass is therefore not a one-off rescue but a permanent requirement until that entry ages out — which is the friction behind the three asks above. Point 3 confirmed with a fresh artifact
pnpm's own stderr — e.g. No reply needed on my account; adding this as data for whoever picks it up. |
|
Three things your report points at, all verifiable on the tip, and the third one you have already half-identified without the line. The failure has a kind in the type — it just has no pattern
const LOG_KINDS: readonly [PluginInstallFailureKind, RegExp][] = [
['build-blocked', /ERR_PNPM_IGNORED_BUILDS|Ignored build scripts/],
['not-found', /ERR_PNPM_FETCH_404|\bE404\b|404 Not Found|Not Found - GET/],
['no-matching-version', /ERR_PNPM_NO_MATCHING_VERSION|\bETARGET\b|No matching version/],
['disk-full', /\bENOSPC\b|no space left on device/i],
['permission', /\bEACCES\b|\bEPERM\b|permission denied/i],
['integrity', /ERR_PNPM_TARBALL_INTEGRITY|ERR_PNPM_BAD_TARBALL_SIZE|\bEINTEGRITY\b/],
['unknown', /The requested URL returned error: 40[134]\b/],
['network', /\bENOTFOUND\b|\bECONNRESET\b|\bETIMEDOUT\b|…/],
]I ran your message text through that table, in order: nothing matches The irony is that the same policy is already described precisely one state over. The missing pnpm output is path-dependent, and your reproduction is the path where it is by design
Your command was the CLI form ( What the file does say, which is worth keeping
|
|
Thanks — I checked all three against the shipped build rather than the repo, and two of them change my report. The classifier gap is real, in the shipped artifact
You are right about the log, and my ask #3 was wrong as writtenThe path dependence is visible in the shipped files:
So my 206-byte file is the designed shape for a CLI run, not a lost write, and the in-app path already keeps the full transcript. Withdrawn. Your objection to the self-heal half of ask #1 also lands, and I'll take it: a tool that passes What survives is only the naming half. On the CLI, pnpm does print a full remediation — verbatim from the failing run:
The UI has no equivalent, because there is no kind to hang it on. A What the reproduction did surfaceThe narrow escape hatch that message implies — add the entry to function evaluateVersionPolicy(rules, pkgName) {
for (const { nameMatcher, exactVersions } of rules) {
if (!nameMatcher(pkgName)) continue;
if (exactVersions.length === 0) return true;
return exactVersions; // first matching rule returns; later rules are unreachable
}
return false;
}(pnpm 11.7.0 This profile's list contains, in this order, That matches what the failing runs printed: the verification pass flagged exactly One honesty note on the CLI-level experiment: reordering those two lines and changing nothing else turned the same command from exit 1 into exit 0, but a later control run in the original order also passed once the auto-collect had appended more entries to the file. So the CLI flip is not isolated — the run either performs the 252-entry verification pass or skips it entirely, and that boundary moved on its own. The deterministic evidence is the unit-level evaluation above, which uses pnpm's own functions, plus the failing run naming precisely the dead entry. Two knock-on effects, both upstream of this repo:
Also worth writing down, since nothing in the profile reveals it: the cutoff pnpm printed was exactly 24 h before each run, and I don't need your files changed for any of this; I'm reporting it because the classifier you pointed me at is where a DSH user would otherwise never learn any of it. Happy to write the minimal reproducer — fresh profile, small lockfile, both orders — if it helps a pnpm-side report. |
|
Follow-up with two more pieces of evidence on the same failure, from my own machine (DSH 1. A rejected run can already have replaced part of the treeIn the plugin manager's own logs, between So in that flow the policy check fires after pnpm has already pruned 28 packages from 2. There is no rollback on a non-zero pnpm exitFrom the shipped build (
So the tree-replacement hazard is handled for the compatibility denial case (exit code 0, warnings non-empty) and is not handled for a pnpm non-zero exit such as 3. What it cost hereAfter that retry sequence my profile ended up internally inconsistent: Honest limits: (a) I cannot prove which of the seven runs in that window removed the bash directory — only that two rejected runs had already touched the tree and that no rollback path exists for their exit status; (b) those host runs also carried registry noise ( 4. Isolated control run of the same error messageTo see whether the rejection itself is atomic, I reproduced the same violation in a scratch project ( So the check can fire before any linking (tree untouched, atomic) or after it (tree already replaced) depending on the run — the guarantee is order-dependent rather than structural. During the run pnpm also prints its own remediation text: "…run pnpm clean --lockfile and then pnpm install… Alternatively, relax the policy that flagged them." Asks
|
|
Follow-up with new evidence: one bypassed install wedges the whole profile for ~24 h, and the Two host-side failure modes observed on this machine (DSH 1. A single too-young lockfile entry blocks every install run, naming a package you weren't touchingpnpm verifies the entire lockfile against Timeline: Those six runs were attempts to update other packages — The market's own log records that it cannot escape this: The wedge only cleared on the seventh run, when pnpm appended the exclusion itself ( Verified in isolation (scratch project, its own store, Ask: when the lockfile check fails, name the offending (For reference, the market also merged its per-package 2.
|
Follow-up: the same profile has a second, self-inflicted flavour of this failure — and it is a bundled-pnpm version gapNew evidence from the same machine (DSH I hit a state where every The host's own minimumReleaseAgeExclude:
- billion-context@0.1.185 || 0.1.186 || 0.1.189 || 0.1.191 # line ~25, wins
- billion-context@0.1.192 # line ~35, silently ignoredOn pnpm 11.7.0 only the first selector for a given package takes effect; later ones are dropped without a warning. So the explicit exemption for These duplicates are easy to reach through the ordinary flow: when an approval is granted, pnpm appends an entry ( Version bisectMinimal reproduction in a throwaway project (
(Order matters on the failing versions: with So this particular defect is already fixed upstream eight days after the version the host ships, which makes it a host-side gap rather than something for pnpm to act on. The two paths differ in the message only — the resolution path raises What would remove this class of failure on the host side
Local workaround for anyone who lands here first: check for duplicate selectors before assuming the 24 h window is the problem — Select-String -Path "$env:USERPROFILE\.dsh\profiles\<profile>\pnpm-workspace.yaml" -Pattern 'minimumReleaseAgeExclude' -Context 0,20and merge any package that appears twice into a single |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Installing a plugin through the host's own CLI (
dsh plugin --profile <profile> add <pkg>) fails hard whenever the profile's existing lockfile already contains an entry newer than theminimumReleaseAgewindow. The failure has no fallback, does not say which entry tripped the check, and does not persist pnpm's own output to the operation log — so the operator only sees a supply-chain refusal and has to rediscover--config.minimum-release-age=0.Environment
0.2.0-rc.2, Windows x64, desktop profilev24.21.0, bundled pnpm11.7.0Reproduction
Result — exit 1, package.json and the lockfile unchanged:
Adding
--config.minimum-release-age=0makes the same command succeed:Two details that make this worse than it looks:
dsh-ops; the entry that failed is a transitive package (dsh-context@0.66.1) already recorded in the profile lockfile from an earlier day. So once that lockfile holds any too-new entry, every later add / update on that profile fails the same way, and only the bypass flag unblocks it.profiles\<profile>\.plugin-manager\logs\operation-<id>\pnpm.logcontains only the wrapper command it ran ("...DeepSeek Harness.exe" --expose-internals "...pnpm.mjs" add dsh-ops --store-dir ...), not pnpm's stderr — so after the fact the failure cannot be identified from the log, only from the live terminal output.Three asks, all in the host CLI path
operation-<id>/pnpm.log(or a sibling file) so a failed install is diagnosable from the log afterwards.Where this was reported first
This was originally filed as a bug against the community marketplace plugin (dsh-market#818). Its maintainer correctly replied that it is not on the market side: the desktop path installs through
pluginManager.installBundle(spec), which accepts a spec and no pnpm flags, so the market's own non-retry branch is right and it cannot inject the parameter. They asked for it to be reported here instead. This repository has issues disabled, so it is going to Discussions per the README's guidance.Workaround (for anyone hitting it)
Reported as feedback, not as a demand — the workaround is known to work; the cost is that it is undocumented at the point of failure.
All reactions