got this error message: Unhandled Error

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

Why would you think that?

Because it's generally not something that would be done/called often enough and/or compared to other operations (e.g. performing I/O).

I can't imagine there being a measurable difference with these changes.

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

Version

No response

Platform

Darwin Kernel Version 22.4.0 / RELEASE_ARM64_T6020 arm64

Subsystem

No response

What steps will reproduce the bug?

I am not certain how to reproduce it, but it appears that the issue can be reproduced when trying to use the already-open Signal app after the computer has gone to sleep and/or the screen has turned off.

How often does it reproduce? Is there a required condition?

N/A

What is the expected behavior? Why is that the expected behavior?

The expected behavior is a normally functioning Signal app.

What do you see instead?

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5) at assert (node:internal/assert:14:11) at internalConnectMultiple (node:net:1077:3) at afterConnectMultiple (node:net:1532:5)

Additional information

No response

Each call to ssh.sftp() is a separate channel. If you are performing multiple transfers on the same SFTP channel, then simply only stop the transfer you want. If you're using sftp.fast*(), you either need to create your own solution and/or keep an eye on this feature request. Otherwise if you're using a file stream, you simply just need to destroy it.

sftp.end() should close the channel.

Error encountered using Signal:

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

Version

No response

Platform

macOS 11.7

Subsystem

No response

What steps will reproduce the bug?

no idea

How often does it reproduce? Is there a required condition?

don't know

What is the expected behavior? Why is that the expected behavior?

normal operation

What do you see instead?

"unhandled error" and two buttons with: "quit" and "copy an d quit" which I did, see the copied lines below. Signal had to be restarted.

Additional information

Unhandled Error

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

Version

6.20.0

Platform

macOS M1 Pro

Subsystem

No response

What steps will reproduce the bug?

No response

How often does it reproduce? Is there a required condition?

Two days in a row in the morning

What is the expected behavior? Why is that the expected behavior?

No response

What do you see instead?

Unhandled Error

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

Additional information

No response

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

Version

18.14.0

Platform

Darwin C02FG53PMD6R.local 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 21:00:17 PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64 x86_64

Subsystem

Signal 6.20.0 production (Intel) Looks like signalapp/Signal-Desktop#6456

What steps will reproduce the bug?

ETA: This was from the Signal messaging app. I got this while waking up my Mac and again when switching to the Signal app.

How often does it reproduce? Is there a required condition?

Not sure yet. I've seen it twice today but then successfully restarted Signal and browsed and sent messages.

What is the expected behavior? Why is that the expected behavior?

Successful

What do you see instead?

Popup window from Signal:

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals.
Please open an issue with this stack trace at https://github.com/nodejs/node/issues
at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

Second occurence:

"Unhandled Error"

Please open an issue with this stack trace at https://github.com/nodejs/node/issues

    at new NodeError (node:internal/errors:399:5)
    at assert (node:internal/assert:14:11)
    at internalConnectMultiple (node:net:1077:3)
    at afterConnectMultiple (node:net:1532:5)

Additional information

Signal debug log

this happened with Signal while it running in the background:

Unhandled Error

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues

at new NodeError (node:internal/errors:399:5)
at assert (node:internal/assert:14:11)
at internalConnectMultiple (node:net:1077:3)
at afterConnectMultiple (node:net:1532:5)

I believe this is a duplicate of https://github.com/nodejs/node/issues/47644

/cc @anonrig

As noted in https://github.com/nodejs/node/issues/46789, do you have a new enough build environment?

Perhaps you need to use the xoauth2 config setting for OAuth 2-based authentication instead of using a password.

root@ubuntu18:~/docker/src# node app.js
/root/docker/src/node_modules/busboy/lib/utils.js:469
    } catch {}
            ^

SyntaxError: Unexpected token {
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:616:28)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/root/docker/src/node_modules/busboy/lib/index.js:3:30)

Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals.

Stack trace: at new NodeError (node:internal/errors:399:5) at assert (node:internal/assert:14:11) at internalConnectMultiple (node:net:1077:3) at afterConnectMultiple (node:net:1532:5)

Version 6.20.0 (freshly updated)

v6.x is no longer supported. For supported versions, please see the information here.

Affected URL(s)

https://web.facebook.com/yusufsuryanata99

Description of the problem

Okay

I just wanted to voice my support for these changes as I was running into an issue with virtio-scsi qemu dvdrom devices not showing up in /dev/disk/by-path, but with the changes detailed in https://github.com/eudev-project/eudev/issues/242#issuecomment-1331238300 the symlink is now visible.

@yodayox Are you still not interested in submitting a PR? If so, I can submit one (although I am not familiar with the code being changed here) as I'd rather not have to maintain a patch on top of eudev...

If rollup works with npm and not pnpm, then I would say it's a pnpm problem.