External youtube-dl-exec library crashes NR

General
1

In January 2022 - I had the following flow, using a function Node to get information about a YouTube video. It uses the youtube-dl-exec library.

The function code was quite simple:

const myTimeout = setTimeout(NoReturn, 5000);

youtubeDlExec(msg.payload, {dumpSingleJson: true}).then(output => {
    msg.payload = output;
    clearTimeout(myTimeout);
    node.send(msg);
    node.done();
    });


function NoReturn(){
 msg.payload = "No response";
 node.send(msg);
 node.done();
}

In case a wrong URL was specified - I became - as expected a "No response" message.

Now NR crashes complete. ... and I don't know why.

I tried to change the function code - to use try... , catch ... . But nothing helps.
I have update NR and this library to the newest version.

If a correct URL is provided - the function works well. So what can I do make this function resistent against wrong inputs without crashing NR.??

Here is the complete flow:

[
    {
        "id": "6452b757c45baa7c",
        "type": "function",
        "z": "7fd8fff652f013f7",
        "name": "youtube-dl-exec",
        "func": "const myTimeout = setTimeout(NoReturn, 5000);\n\nyoutubeDlExec(msg.payload, {dumpSingleJson: true}).then(output => {\n    msg.payload = output;\n    clearTimeout(myTimeout);\n    node.send(msg);\n    node.done();\n    });\n\n\nfunction NoReturn(){\n msg.payload = \"No response\";\n node.send(msg);\n node.done();\n}\n\n",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [
            {
                "var": "youtubeDlExec",
                "module": "youtube-dl-exec"
            }
        ],
        "x": 500,
        "y": 1700,
        "wires": [
            [
                "68d5040203c27b4d"
            ]
        ]
    },
    {
        "id": "6c856e483f45a597",
        "type": "inject",
        "z": "7fd8fff652f013f7",
        "name": "6xKWiCMKKJg",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "https://www.youtube.com/watch?v=6xKWiCMKKJg",
        "payloadType": "str",
        "x": 300,
        "y": 1700,
        "wires": [
            [
                "6452b757c45baa7c"
            ]
        ]
    },
    {
        "id": "68d5040203c27b4d",
        "type": "debug",
        "z": "7fd8fff652f013f7",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 710,
        "y": 1700,
        "wires": []
    },
    {
        "id": "9904e080ec7c54de",
        "type": "inject",
        "z": "7fd8fff652f013f7",
        "name": "Err6xKWiCMKKJg",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "https://www.youtube.com/watch?v=Err6xKWiCMKKJg",
        "payloadType": "str",
        "x": 310,
        "y": 1660,
        "wires": [
            [
                "6452b757c45baa7c"
            ]
        ]
    }
]

So - OK I updated all NR - but what has so fundamentally changed - that this function node is able to crash NR?

The last version when it didn't crash was 2.1.4 or earlier.

2

You are missing any error handling in the call to youtubeDlExec. It returns a Promise object, so you need to define a catch function:

youtubeDlExec(msg.payload, {dumpSingleJson: true}).then(output => {
    msg.payload = output;
    clearTimeout(myTimeout);
    node.send(msg);
    node.done();
}).catch(err => {
    // An error has been returned by the Promise.
    // Do something with it...
});
3

Great this works. Many thanks!!!!

4

Only one question - I am happy that this works in that way, but in the past I have not to catch this. And in general is this not a problem, that the whole system crashed? I have no problem as I know now how to handle this, but I think the system should at least be able to handle this somehow?

5

There is no safe way to handle uncaught, asynchronous errors. We have no way of knowing what state the entire system has been left in and whether it is safe to let it continue running.

To quote the Node.js docs:

The correct use of 'uncaughtException' is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process. It is not safe to resume normal operation after 'uncaughtException'.

6

OK - but why was this not a problem 2 months ago? What has been changed? OK it can be the library has changed as well. In the past there was simple no answer - this is why it was possible to catch the error with a simple timeout.

7

I have a memory of that in older versions of nodejs, a promise without a catch would not crash an application. About nodejs v10 they started putting warning in the console that this would change & would exit nodejs - I think this was introduced in v14 or v16 (I forget)

8

2 months ago I had at least nodejs v14 - but it can be that I updated it to v16. I can try on another systems with v14 - but this would explain the change in behavior. :wink: - Thanks.
.

Edit: Ok crashed also on nodejs v14. I do not know - why it was not necessary in the past.

9

I found a copy of the message. It's funny how time flies.

Deprecation warning in Node 7 states that this will be changed in future Node.js versions:

Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

So it might have changed in V8 or v10

10

It was definitely not such a long time ago. As I said - in January 2022 it works well with the code in my first post in this thread. I only thought there was an internal mechanism in NR which handled this exception - if not - I do not know and may be it is not worthy to think about it, but I thought if we definitely know why it was working, we can do something to improve stability.

11

Just as an aside - the youtube-dl code is pretty flaky and does not work well all the time - it slows down dramatically when downloading videos.

The better option is

yt-dlp

Craig

12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.