"Error: write after end" followed by npm-register crashing

[jessebye]

Just started seeing this error on our npm-register server (running version 2.5.2) last night:

Error: write after end
at writeAfterEnd (_stream_writable.js:236:12)
at PassThrough.Writable.write (_stream_writable.js:287:5)
at IncomingMessage.ondata (_stream_readable.js:642:20)
at emitOne (events.js:115:13)
at IncomingMessage.emit (events.js:210:7)
at addChunk (_stream_readable.js:266:12)
at readableAddChunk (_stream_readable.js:253:11)
at IncomingMessage.Readable.push (_stream_readable.js:211:10)
at HTTPParser.parserOnBody (_http_common.js:140:22)
at TLSSocket.socketOnData (_http_client.js:454:20)
at emitOne (events.js:115:13)
at TLSSocket.emit (events.js:210:7)
at addChunk (_stream_readable.js:266:12)
at readableAddChunk (_stream_readable.js:253:11)
at TLSSocket.Readable.push (_stream_readable.js:211:10)
at TLSWrap.onread (net.js:585:20)

After this error, the app dies.

[jessebye]

Not sure if related, but seeing this in the logs too (app does not crash though):

logging error with Opbeat: { uuid: '7335b2e5-c94a-48d5-8061-4eaa09fc8f0f' }
Error: write EPIPE
at _errnoException (util.js:1026:11)
at WriteWrap.afterWrite [as oncomplete] (net.js:858:14)

[dgautsch]

@jessebye do you know what user actions were taking place when the error occured?

[jessebye]

@dgautsch Most likely just npm install. We have a lot of users and servers using the registry, so it's hard to say what action was happening at a given time.

[jdx]

this means the response timed out. Koa-timeout kills the request but then the code still tries to write to it.

[jessebye]

@jdxcode maybe a case for better error handling then? This was crashing npm-register every time. It's not happening right now, probably because whatever URL was timing out isn't timing out any more, but I would prefer to not need to manually restart the npm-register process when there are timeouts like this 😄

[jdx]

I’m certainly not arguing this is ok behavior, I’m just giving some color around why it’s happening. I’ve seen these errors come in on our installation and I don’t know if it’s causing the server to crash or not, but because we run this on a couple of instances in tandem and if one crashes another one simply replaces it it’s not causing us any practical issue.

My point again isn’t that this is okay, but it’s also not something worth investigating from my side right now. I’ll certainly accept a PR if someone wants to explore the behavior the CLI has on timeouts though.

[dgautsch]

@jessebye I'll have to narrow down the steps to reproduce. I can start going over the code and looking for areas where we're not error handling.

[tomasfse]

Well, I'm having the same error as @jessebye, the error:

logging error with Opbeat: { uuid: '7335b2e5-c94a-48d5-8061-4eaa09fc8f0f' }
Error: write EPIPE
at _errnoException (util.js:1026:11)
at WriteWrap.afterWrite [as oncomplete] (net.js:858:14)

Is repeated a lot of times, and it finally die with the error:
Error: write after end

However I'm concerned with the opbeat login error.

Why is it trying to loggin to opbeat if I have not the opbeat details defined? I think since Opbeat is an online profiling platform the initialization must be optional.

Maybe an ENV variable to disable/enable opbeat?

Thanks

[dgautsch]

@protheantom does this happen during npm install like jessebye mentioned?

[tomasfse]

@dgautsch yes, also during the npm install (version 2.6.2)

I'm running it inside a Docker container, I think it isn't related, but could be... @jessebye are you running npm-register in a container too?

[jessebye]

@protheantom not running in Docker. But I see the same logging errors when npm-register crashes. We are running into this bug seemingly once every few weeks now. Just about ready to jump over to a different NPM registry solution since we've had so much trouble with this 😢

[holms]

Saddest part that other solutions doesn't follow 12factorapp and this brings troubles deploying registry with a docker. I mean how can people use only config file for configuration? This solution doesn't scale. That's why this project must live!

[dgautsch]

Does this still persist with v2.8.1?