[crash] npm ERR! cb() never called!

priority:medium
triaged
cli

(Jonathan Grimes) #21

We’ve tried raising limits. Doesn’t fix it for my teammate. :(


(Sina Syrous) #22

I too have the same problem unfortunately, raising the limits didn’t work here either.
An interesting note however is that I have several repos where some of them work totally fine and some of them get this error…

node -v
10.8.0

npm -v
6.2.0

CONCLUSION:
Current fix for me was to downgrade npm 6 => 5 and node 10 => 8


(Vivek Manikandan D) #23

Been stuck with this issue since yesterday… Finally I have tried this -->
Current fix for me was to downgrade npm 6 => 5 and node 10 => 8

Previously my node version was 8.11.3 and npm version was 6.3.0
After downgrading my npm version to 5.0.0 (npm install -g npm@5.0.0) Nativescript installed successfully…
Thank you very much sigsiroos


(Garth Kidd) #24

Seen despite ulimit -n 20000, Linux, in an unmodified official node:8 container with npm 5.6.0 on node 8.11.4. After npm i -g npm@6, got cb() never called again after a perhaps more useful traceback:

Unhandled rejection Error: invalid config key requested: error
    at pudGet (/usr/local/lib/node_modules/npm/node_modules/figgy-pudding/index.js:31:11)
    at FiggyPudding.get (/usr/local/lib/node_modules/npm/node_modules/figgy-pudding/index.js:13:12)
    at Object.get (/usr/local/lib/node_modules/npm/node_modules/figgy-pudding/index.js:71:16)
    at Object.checkData (/usr/local/lib/node_modules/npm/node_modules/ssri/index.js:232:22)
    at write (/usr/local/lib/node_modules/npm/node_modules/cacache/lib/content/write.js:34:31)
    at putData (/usr/local/lib/node_modules/npm/node_modules/cacache/put.js:29:10)
    at Object.x.put (/usr/local/lib/node_modules/npm/node_modules/cacache/locales/en.js:28:37)
    at readFileAsync.then.data (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/fetchers/file.js:38:28)
    at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
    at Promise._fulfill (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18)
    at /usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/nodeback.js:42:21
    at /usr/local/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:78:16

… which is odd, because I haven’t set the NPM configuration in this container.


(Garth Kidd) #25

Traced that to issue 20424, blew away package-lock.json, got a successful npm install --prod-only with npm 5.6.0 and no change to the ulimit.


(Ans de Nijs) #26

Same error here. Using NPM version 6.2.0 and Node version 8.11.3. I’m using the Angular CLI version 6.0.8
My error log showed the following:

14872 silly extract date-fns@2.0.0-alpha.7 extracted to D:\Angular\Rijksoverheidstheme\RijksoverheidsthemeAnalysis\node_modules.staging\date-fns-80532216 (63460ms)
14873 timing npm Completed in 155205ms
14874 error cb() never called!
14875 error This is an error with npm itself. Please report this error at:
14876 error https://npm.community

I’ll try downgrading and watch what happens.


(Ans de Nijs) #27

Downgrading to NPM version 5.6.0 worked for me (still with same Node.js version 8.11.3). I looked up which npm version would be suitable for the Node.js version I had in this table: https://nodejs.org/en/download/releases/

npm install -g npm@5.6.0

(Joshua Chaitin Pollak) #28

This seems to happen pretty consistently for me, Mac OS 10.13.6, npm 6.4.0, node 10.4.1, I get this stack trace:

Unhandled rejection Error: invalid config key requested: error
    at pudGet (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/figgy-pudding/index.js:31:11)
    at FiggyPudding.get (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/figgy-pudding/index.js:13:12)
    at Object.get (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/figgy-pudding/index.js:71:16)
    at Object.checkData (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/ssri/index.js:232:22)
    at write (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/cacache/lib/content/write.js:34:31)
    at putData (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/cacache/put.js:29:10)
    at Object.x.put (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/cacache/locales/en.js:28:37)
    at readFileAsync.then.data (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/pacote/lib/fetchers/file.js:38:28)
    at tryCatcher (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
    at Promise._fulfill (/Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18)
    at /Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/bluebird/js/release/nodeback.js:42:21
    at /Users/jpollak/.rush/npm-6.4.0/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:78:16

(similar to a stack trace above)

Worse, npm seems to stall downloading packages and never completes.


(Joshua Chaitin Pollak) #29

The PR in https://github.com/npm/npm/issues/20424 does not appear to be comprehensive enough:

it looks like ssri and/or cacache pass opts objects into figgy-pudding that don’t always provide opts.error, opts.size, etc, but figgy-pudding seems to be validating that the opts object is properly specified. This seems like a structural problem with these libraries and I’m not sure how to fix it.


(Nick Oliver) #30

FWIW we’ve seen this behavior occur on our CI behind a firewall when package-lock.json had entries from registry.npmjs.com instead of just our internal registry and also when using relative package paths (ex: "name": "../name") that do not exist.

(For the former situation, this bug might be related to another behavior I’ve noticed: if registry.npmjs.com had been previously used for a different project, when using a different registry to install and generate a new package-lock.json the generated lock file contains references to registry.npmjs.com instead of the specified registry. The only workaround I’ve found for this is to clear out the cache and attempt the install again.)


(Joshua Chaitin Pollak) #31

We are starting to suspect this problem happens more with projects with large dependency sets.


(GLE) #32

It seems to be linked, in our case for little projects it works (not a lot of dependencies). But for larger projects (with a lot of dependencies, it failed).


(Matteo Collina) #33

I can confirm this happens sporadically to me with https://github.com/fastify/fastify, https://github.com/fastify/fastify-react, https://github.com/pinojs/pino and many more.

All of those pull in a vast number of (similar) dependencies in development.

The version of Node.js does not influecence this, it happens to both Node 8 and Node 10 with npm 6.4.1.


(Matteo Collina) #34

Unfortunately this is happening more and more for me, making npm almost unusable.

@zkat I would like to help fixing it. Would you mind recommending some debugging strategy?


(Matt Fletcher) #35

I’m unable to recreate the bug, using the latest node and npm. My ulimit was set to unlimited, so I lowered it to a measly 500 and tried again, still works for me. Running OSX 10.12.1 … maybe not helpful but just putting it out there.


(Aronduby) #36

I was getting the same error running on windows 10. Was playing around with installing using other versions and started noticing a 401 error buried in the output from them. Once I got the custom registry setup properly everything installed right with the old version so I deleted it all and tried with the latest and everything worked. Maybe errors are getting swallowed with latest leading to this error?

Windows 10 using nvm for windows

latest (had cb error)

  • node 10.10.0
  • npm 6.4.1

downgraded to (got 401 error)

  • node 8.11.4
  • npm 5.6.0

(Stan) #37

Thanks for the tip, I downgraded and finally got passed the cb() error. For what it’s worth it worked on node v10.10.0 with npm 5.6.0 for me :)

EDIT: Scratch that, didn’t work with 10.10.0, downgrading node to 8.11.3 now :sunny:


(Patlachance) #38

From the log provided, it seems you’re running npm behind a proxy.

We had the same “npm ERR! cb() never called” when installing packages such as probot.

In our case the problem was not related to npm as it was fixed by increasing the number of file descriptors on the squid proxy server by adding the following to /etc/sysconfig/squid
ulimit -n "131070"


(Dane Powell) #39

I got this error when a local development dependency (i.e. “my-package”: “file:…/my-package”) didn’t exist. Of course that’s partially my fault for not ensuring that it existed, but I think the installer should check whether the directory exists instead of throwing this completely cryptic error.

Edit: in trying to reproduce this with another package I got a different error, so maybe I did get bitten by the same underlying bug originally: Could not install from "../my-package" as it does not contain a package.json file.


(Spiltcoffee) #40

I had a similar error, I failed to create a local development dependency correctly before running install in another project that depended on it, and got this cb() error.

(Thanks for your reply by the way, @danepowell - it got me on the right track for fixing my own issue :smiley:)