pnpm dedupe never revalidates cached registry metadata for locked versions, so it cannot apply what dedupe --check reports in CI #17208

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

12.15.0

Which area(s) of pnpm are affected? (leave empty if unsure)

Lockfile, Dependencies resolver

Link to the code that reproduces this issue or a replay of the bug

Self-contained steps below.

Reproduction steps

This simulates a metadata cache entry that was written before the registry deprecated a version. Renaming the key keeps the mirror's byte offsets valid:

mkdir repro && cd repro
echo '{"name":"repro","private":true,"packageManager":"pnpm@12.15.0","dependencies":{"@opentelemetry/propagator-jaeger":"1.25.1"}}' > package.json

pnpm install --lockfile-only --config.cache-dir=$PWD/.cache   # lockfile records `deprecated:`

# simulate a cache entry from before the deprecation
F=$(find .cache -name propagator-jaeger.jsonl)
LC_ALL=C sed -i '' 's/"deprecated":/"deprecatex":/g' "$F"   # GNU: sed -i
sed -i '' '/deprecated: /d' pnpm-lock.yaml

pnpm dedupe --config.cache-dir=$PWD/.cache                   # exit 0, `deprecated:` is NOT added
pnpm install --lockfile-only --config.cache-dir=$PWD/.cache  # `deprecated:` is NOT added
pnpm dedupe --check --config.cache-dir=$PWD/.cache           # exit 0
pnpm dedupe --check --config.cache-dir=$PWD/.fresh           # exit 1 (empty cache)

The same thing happened with a real cache entry, without editing anything. My mirror for @opentelemetry/propagator-jaeger was written on 2026-10-06 ("modified":"2026-08-31T16:41:38.327Z"). The registry deprecated 1.25.1 on 2026-10-20 at 21:02 UTC. On 2026-10-21, pnpm dedupe still answered from that mirror and never asked the registry.

Describe the Bug

Follow-up to #17198. The root cause is separate from the --check comparison that #17199 fixed.

A cached metadata entry that contains the locked version never gets refreshed. In metadata_cache_policy.rs, mirror_may_answer lets an online pick use the mirror unless the registry marked the response uncacheable, and nothing expires the entry. So mutable registry metadata (deprecated here) stays as old as the oldest cache entry on each machine.

The practical effects:

• In pnpm dedupe --check fails when only registry metadata (deprecated) changed, even though "no dependency resolution would change" #17198, CI failed with ERR_PNPM_DEDUPE_CHECK_ISSUES ... "Run pnpm dedupe to apply the changes above." Running pnpm dedupe locally changed nothing, because the local cache predates the deprecation. The suggested fix only works after clearing the cache (--config.cache-dir=$(mktemp -d)), and nothing points to that.
• The same commit produces different lockfiles depending on how old the cache is on the machine that wrote it. fix(dedupe): ignore deprecation notices in dedupe --check #17199 stops --check from failing on this, but it doesn't make the output consistent.
• Deprecation warnings during install and dedupe go missing on machines with an older cache. We saw 16 deprecated subdependencies locally and 18 in CI for the same lockfile.

Existing deprecated: lines are not removed by a stale-cache run, so there is no lockfile flip-flopping. The drift only goes one way.

Expected Behavior

pnpm dedupe re-resolves the whole graph and is the command --check tells you to run, so it should revalidate cached metadata (a conditional request with the stored ETag is cheap). That way it can apply what --check reports. Alternatively, mirror entries could have a maximum age after which online commands revalidate them.

If answering from the mirror is intentional, then the --check error message could mention that local metadata may be stale and how to refresh it.

Which Node.js version are you using?

24.22.1

Which operating systems have you used?

• macOS
• Windows
• Linux