[BUG] ETARGET installing package I just published (not invalidating cache?)

isaacs commented 2 years ago

Is there an existing issue for this?

[X] I have searched the existing issues

This issue exists in the latest npm version

[X] I am using the latest npm

Current Behavior

Publish libtap 1.3.0 cd to tap try to install libtap@1.3.0 ETARGET forever, even though npm view libtap version reports 1.3.0

$ npm view libtap version
1.3.0

$ npm i libtap@1.3.0
npm ERR! code ETARGET
npm ERR! notarget No matching version found for libtap@1.3.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2022-03-05T19_32_50_810Z-debug-0.log

$ npm -v
8.5.3

Expected Behavior

Should fetch version 1.3.0 from registry

Steps To Reproduce

See description

Environment

npm: 8.5.3
Node.js: v17.6.0
OS Name: Darwin
System Model Name: Darwin moxy.lan 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000 arm64
npm config:

; "user" config from /Users/isaacs/.npmrc

@npm:registry = "https://npm.pkg.github.com/" 
//npm.pkg.github.com/:_authToken = (protected) 
//npm.toddself-pkg1.ghaedev.com/:_authToken = (protected) 
//registry.internal.npmjs.com/:_authToken = (protected) 
//registry.npm.red/:_authToken = (protected) 
//registry.npmjs.org/:_authToken = (protected) 
//registry.npmjs.rocks/:_authToken = (protected) 
access = "public" 
foo = "baz" 
script-shell = "bash" 
sign-git-commit = true 
sign-git-tag = true 

; node bin location = /usr/local/bin/node
; cwd = /Users/isaacs/.npm/_logs
; HOME = /Users/isaacs
; Run `npm config ls -l` to show all defaults.

Logs and relevant cache files attached below

2022-03-05T19_35_59_088Z-debug-0.log

npm-view-libtap-version.log

_cacache.zip

isaacs commented 2 years ago

It does eventually seem to work, but only after about 5 minutes or so. So it looks like we're holding onto cache without revalidating it, even though the ETag has changed. Since that's within the "serve from cache without revalidating" window, maybe that's "correct" behavior, but interestingly, npm ls doesn't do that.

I think at least, maybe make-fetch-happen could be smart enough to say "I just did a POST to that url, so let's make sure to always revalidate that cache entry", or something?

nlf commented 2 years ago

we do make efforts to invalidate the cache when a package is published, but npm view being unaffected while npm install is makes it sound like we're possibly invalidating the full packument correctly but not the corgi. we'll look into this one!

kalinkrustev commented 1 year ago

Looks like a todo, which did not happen...

jsjoeio commented 1 year ago

I'm facing this now. We publish each pr for coder/code-server under the package name @coder/code-server-pr and tag it with the PR number. When I run npm install --unsafe-perms @coder/code-server-pr@5673 I get:

npm ERR! code ETARGET
npm ERR! notarget No matching version found for @coder/code-server-pr@5673.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jp/.npm/_logs/2022-10-20T18_33_28_214Z-debug-0.log

yet when I run npm view @coder/code-server-pr, I see it in the list:

5673: 4.7.1-5673-3c17798eb377432f160f3aef7cad61bb2a26a83f
latest: 4.1.0-4972-4f800181a0de4ee60389f9d90200bb088e7d8a2e

If I use the exact version i.e. npm install @coder/code-server-pr@4.7.1-5673-3c17798eb377432f160f3aef7cad61bb2a26a83f it works.

original001 commented 1 year ago

I'm experiencing the same issue. When I publish package to my components library, my CI immediatly fall, because it cannot install versions in updated package.json.

Is there any update of this?

lionello commented 5 months ago

Doing npm install --force … doesn't work, but running npm cache clean --force seems to have purged whatever was keeping it from contacting the registry.

vangenechtenbert commented 4 months ago

Same issue here in npm 10.2.3

cniweb commented 3 months ago

Same issue here in npm v10.2.3 (with node v18.18.1)

iamrakesh commented 2 months ago

We too ran into the same problem since move to NodeJs to 20.x (from NodeJs 14.x). Our CI setup, builds/publishes a NPM package and is consumed by other project in the same build cycle at a later point. We were able to solve/work it around by using 'prefer-online=true' instead of 'prefer-offline=true' in our .npmrc file.

silverwind commented 1 week ago

My experience with this bug:

If one installs a package within the first ~30s of publish, it always fails with ETARGET. This will then trigger a bad negative cache and in may then fail for up to 5 minutes.
If one waits around ~60s after publish and the install, it works reliably and does not trigger the bad cache.

The registry API always gives the correct version, making me believe this is a local cache problem in the cli.

npm / cli