node-red

commit time in 2 hours ago

HiTECHGuardian started node-red/node-red

started time in 1 hour ago

push

node-red-flow-library push node-red/catalogue.nodered.org

node-red-flow-library

Update catalogue

commit sha： 475bb1cb92f07b794105254977dac9d766894279

push time in 2 hours ago

commit time in 5 hours ago

mjavadhpour started node-red/node-red

started time in 2 hours ago

push

node-red-flow-library push node-red/catalogue.nodered.org

node-red-flow-library

Update catalogue

commit sha： eb694d745256fa3115762a02efa7c1bd9d3063f6

push time in 5 hours ago

artmsv started node-red/node-red

started time in 5 hours ago

fabriciomsdev started node-red/node-red

started time in 6 hours ago

My-Random-Thoughts issue node-red/node-red

My-Random-Thoughts

My-Random-Thoughts NONE

createdAt 8 hours ago

Text Undo/Redo does not work after clicking expand button

Current Behavior

When expanding the edit window of a node that allows multi-line text entry (function node) the undo/redo buffer is flushed.

I am guessing that when expanding you are creating a new textbox and destroying the current one copying the existing text from one to the other.

Expected Behavior

The Undo/Redo buffer should follow expansion

Steps To Reproduce

Add a function node to a page. Double-click node to open the editor pane Write some text Perform some undo/redo operations to ensure it works Click the Expand button top-right of editor window Perform some undo/redo operations again, they no longer work for previous text entry

Example flow

N/A

Environment

Node-RED version: 3.0.0 b2 (also happens in v2.2.2 so not a newly created bug)
Node.js version: 18.1
npm version: 8.8.0
Platform/OS: Linux 5.13.0-41-generic x86_64
Browser: Firefox 100

b10up issue comment node-red/node-red

b10up

b10up NONE

needs-info

TCP sockets crashing when a client disconnect unexpectedly

Current Behavior

TCP out node in listening mode not working properly, if a client disconnects unexpectedly, it throws a socket error and some of the still active clients stop receiving data.

Expected Behavior

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The rest of the clients still receiving the data

Steps To Reproduce

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The node red console writes socket error, the other clients randomly stops receiving data

Example flow

[
    {
        "id": "69b8f80db494f181",
        "type": "tcp out",
        "z": "360d032be0511281",
        "name": "",
        "host": "",
        "port": "50000",
        "beserver": "server",
        "base64": false,
        "end": false,
        "tls": "",
        "x": 520,
        "y": 120,
        "wires": []
    },
    {
        "id": "d8083637a25dd4a4",
        "type": "trigger",
        "z": "360d032be0511281",
        "name": "",
        "op1": "",
        "op2": "0",
        "op1type": "date",
        "op2type": "str",
        "duration": "-250",
        "extend": false,
        "overrideDelay": false,
        "units": "ms",
        "reset": "",
        "bytopic": "all",
        "topic": "topic",
        "outputs": 1,
        "x": 280,
        "y": 120,
        "wires": [
            [
                "69b8f80db494f181"
            ]
        ]
    },
    {
        "id": "50c6bd3df2d0fe6e",
        "type": "inject",
        "z": "360d032be0511281",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "x": 140,
        "y": 40,
        "wires": [
            [
                "d8083637a25dd4a4"
            ]
        ]
    }
]

Environment

Node-RED version:
Node.js version:
npm version:
Platform/OS:
Browser:

b10up

Hi, of course: 19 May 14:43:22 - [info] Node-RED version: v3.0.0-beta.2 19 May 14:43:22 - [info] Node.js version: v16.15.0 19 May 14:43:22 - [info] Windows_NT 10.0.22000 x64 LE [email protected], Browser: Google Chrome 101.0.4951.67

Steve-Mcl issue comment node-red/node-red

Steve-Mcl

Steve-Mcl NONE

TCP sockets crashing when a client disconnect unexpectedly

Current Behavior

TCP out node in listening mode not working properly, if a client disconnects unexpectedly, it throws a socket error and some of the still active clients stop receiving data.

Expected Behavior

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The rest of the clients still receiving the data

Steps To Reproduce

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The node red console writes socket error, the other clients randomly stops receiving data

Example flow

[
    {
        "id": "69b8f80db494f181",
        "type": "tcp out",
        "z": "360d032be0511281",
        "name": "",
        "host": "",
        "port": "50000",
        "beserver": "server",
        "base64": false,
        "end": false,
        "tls": "",
        "x": 520,
        "y": 120,
        "wires": []
    },
    {
        "id": "d8083637a25dd4a4",
        "type": "trigger",
        "z": "360d032be0511281",
        "name": "",
        "op1": "",
        "op2": "0",
        "op1type": "date",
        "op2type": "str",
        "duration": "-250",
        "extend": false,
        "overrideDelay": false,
        "units": "ms",
        "reset": "",
        "bytopic": "all",
        "topic": "topic",
        "outputs": 1,
        "x": 280,
        "y": 120,
        "wires": [
            [
                "69b8f80db494f181"
            ]
        ]
    },
    {
        "id": "50c6bd3df2d0fe6e",
        "type": "inject",
        "z": "360d032be0511281",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "x": 140,
        "y": 40,
        "wires": [
            [
                "d8083637a25dd4a4"
            ]
        ]
    }
]

Environment

Node-RED version:
Node.js version:
npm version:
Platform/OS:
Browser:

Steve-Mcl

Hi, can you please fill out the Environment details - this is important for us to assess the situation.

b10up issue node-red/node-red

b10up

b10up NONE

TCP sockets crashing when a client disconnect unexpectedly

Current Behavior

TCP out node in listening mode not working properly, if a client disconnects unexpectedly, it throws a socket error and some of the still active clients stop receiving data.

Expected Behavior

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The rest of the clients still receiving the data

Steps To Reproduce

1:Configure a tcp-out node in listen mode (in my example, write timestamp every 1 seconds) 2:Connect with multiple clients ( putty, telnet, localhost in my case, but i tested also from multiple external clients) 3:Kill a terminal from task manager or plug off the ethernet from a remote client 4:The node red console writes socket error, the other clients randomly stops receiving data

Example flow

[ { "id": "69b8f80db494f181", "type": "tcp out", "z": "360d032be0511281", "name": "", "host": "", "port": "50000", "beserver": "server", "base64": false, "end": false, "tls": "", "x": 520, "y": 120, "wires": [] }, { "id": "d8083637a25dd4a4", "type": "trigger", "z": "360d032be0511281", "name": "", "op1": "", "op2": "0", "op1type": "date", "op2type": "str", "duration": "-250", "extend": false, "overrideDelay": false, "units": "ms", "reset": "", "bytopic": "all", "topic": "topic", "outputs": 1, "x": 280, "y": 120, "wires": [ [ "69b8f80db494f181" ] ] }, { "id": "50c6bd3df2d0fe6e", "type": "inject", "z": "360d032be0511281", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 140, "y": 40, "wires": [ [ "d8083637a25dd4a4" ] ] } ]

Environment

Node-RED version:
Node.js version:
npm version:
Platform/OS:
Browser:

RealFlachmann issue node-red/nrlint

RealFlachmann

RealFlachmann NONE

'no-duplicate-http-in-urls' detects

Current Behavior

detecting duplicates is a great function of nrLint.

But it is common use, that the same URL will be used multiple times with different methods, e.g. for GET, POST, PUT, DELETE, etc. nrLint detects these as duplicates, but in fact they are not.

Here, all calls are names "/demo", but with different methods: grafik

Expected Behavior

Methods must be taken into account as well to identify duplicates.

Steps To Reproduce

No response

Example flow

No response

Environment

No response

RealFlachmann issue comment node-red/nrlint

RealFlachmann

RealFlachmann NONE

'no-duplicate-http-in-urls' detects

Current Behavior

detecting duplicates is a great function of nrLint.

But it is common use, that the same URL will be used multiple times with different methods, e.g. for GET, POST, PUT, DELETE, etc. nrLint detects these as duplicates, but in fact they are not.

Here, all calls are names "/demo", but with different methods: grafik

Expected Behavior

Methods must be taken into account as well to identify duplicates.

Steps To Reproduce

No response

Example flow

No response

Environment

No response

RealFlachmann

Yes, true, my beta was #1. Ok, cool, that it's fixed! :-)

RealFlachmann issue comment node-red/nrlint

RealFlachmann

RealFlachmann NONE

Dummy Names for Functions and Links clashes nrLint Check

Current Behavior

As discussed in https://discourse.nodered.org/t/node-red-3-0-0-beta-2-released/62698/28, so that this doesn't get missed. Also see https://github.com/node-red/node-red/issues/3618.

nrLint rules 'no-unnamed-functions' and 'no-unnamed-links' do not work with NR 3.0 automatic node naming.

Even if nodes now get dummy names, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

Expected Behavior

No response

Steps To Reproduce

No response

Example flow

No response

Environment

No response

RealFlachmann

commit time in 9 hours ago

I fully agree it would be better for the user to set meaningful names - but the purpose of the generated default name is to help those users who don't rename things. Thank you. :-)

The resolution for this issue will be either: * add a 'no-default-named-functions/links` rules that specifically looks for nodes with the generate names * add an option to the existing rules to also consider the generated names I personally don't mind as long as we get that function.

push

node-red-flow-library push node-red/catalogue.nodered.org

node-red-flow-library

Update catalogue

commit sha： 4dde78ccef8d9cec45c8d9e73ff3918e246d82a9

push time in 9 hours ago

knolleary issue comment node-red/node-red

knolleary

knolleary NONE

wontfix

Flow Title cannot be changed

Current Behavior

In 3.0.0 beta the flow title / name / label cannot be changed any more. The appropriate field does not exist.

Also the comment or documentation tab is not available any more.

Expected Behavior

Flow label can be changed.

Steps To Reproduce

grafik

Example flow

paste your flow here

Environment

Node-RED version: 3.0 beta
Node.js version: 16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

knolleary

As mentioned on the beta forum post - if you find issues with the beta, please add comments to the forum post rather than raise issues.

knolleary issue comment node-red/nrlint

knolleary

knolleary NONE

'no-duplicate-http-in-urls' detects

Current Behavior

detecting duplicates is a great function of nrLint.

But it is common use, that the same URL will be used multiple times with different methods, e.g. for GET, POST, PUT, DELETE, etc. nrLint detects these as duplicates, but in fact they are not.

Here, all calls are names "/demo", but with different methods: grafik

Expected Behavior

Methods must be taken into account as well to identify duplicates.

Steps To Reproduce

No response

Example flow

No response

Environment

No response

knolleary

Duplicate of #19 - the fix has been in the code for sometime, but it hasn't been released yet.

We will get a new version published once we have resolved #30

Steve-Mcl issue comment node-red/node-red

Steve-Mcl

Steve-Mcl NONE

Dummy Names for Functions and Links clashes nrLint Check

Current Behavior

As discussed in https://discourse.nodered.org/t/node-red-3-0-0-beta-2-released/62698/28, so that this doesn't get missed.

Expected Behavior

nrLint keeps its functionality to detect unnamed functions and links.

Even if a nodes now get dummy namen, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

Steps To Reproduce

No response

Example flow

No response

Environment

Node-RED version: 3.0 beta
Node.js version: v16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

Steve-Mcl

@knolleary my bad, I suggested this repo to the OP because I read your "We could certainly add an option to ...." post as "we could add an option to enable / disable auto naming of nodes in the NR core" 😊

knolleary issue comment node-red/nrlint

knolleary

knolleary NONE

Dummy Names for Functions and Links clashes nrLint Check

Current Behavior

As discussed in https://discourse.nodered.org/t/node-red-3-0-0-beta-2-released/62698/28, so that this doesn't get missed. Also see https://github.com/node-red/node-red/issues/3618.

nrLint rules 'no-unnamed-functions' and 'no-unnamed-links' do not work with NR 3.0 automatic node naming.

Even if nodes now get dummy names, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

Expected Behavior

No response

Steps To Reproduce

No response

Example flow

No response

Environment

No response

knolleary

nrLint rules 'no-unnamed-functions' and 'no-unnamed-links' do not work with NR 3.0 automatic node naming.

Yes it does - it identifies the nodes that have a blank name.

Even if nodes now get dummy names, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

To be clear - as I said on the forum - having a name of function 1 is not as meaningless as having a blank name (which then shows as function in the workspace). If you have 10 function nodes, all with blank names, then you have 10 nodes you cannot quickly distinguish. That is markedly different to having function 1, function 2 etc - where you can at least quickly distinguish them when looking in the logs etc.

I fully agree it would be better for the user to set meaningful names - but the purpose of the generated default name is to help those users who don't rename things.

The resolution for this issue will be either:

add a 'no-default-named-functions/links` rules that specifically looks for nodes with the generate names
add an option to the existing rules to also consider the generated names

knolleary issue node-red/node-red

knolleary

knolleary NONE

Dummy Names for Functions and Links clashes nrLint Check

Current Behavior

As discussed in https://discourse.nodered.org/t/node-red-3-0-0-beta-2-released/62698/28, so that this doesn't get missed.

Expected Behavior

nrLint keeps its functionality to detect unnamed functions and links.

Even if a nodes now get dummy namen, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

Steps To Reproduce

No response

Example flow

No response

Environment

Node-RED version: 3.0 beta
Node.js version: v16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

knolleary issue comment node-red/node-red

knolleary

knolleary NONE

Dummy Names for Functions and Links clashes nrLint Check

Current Behavior

As discussed in https://discourse.nodered.org/t/node-red-3-0-0-beta-2-released/62698/28, so that this doesn't get missed.

Expected Behavior

nrLint keeps its functionality to detect unnamed functions and links.

Even if a nodes now get dummy namen, these are still considered to be unnamed, because "function 1" is as meaningless as "function".

Steps To Reproduce

No response

Example flow

No response

Environment

Node-RED version: 3.0 beta
Node.js version: v16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

knolleary

This is a nrlint issue. As you have raised an issue on the nrlint repo already, there's no need to have one on the core as well.

RealFlachmann issue node-red/node-red

RealFlachmann

RealFlachmann NONE

createdAt 10 hours ago

wontfix

Flow Title cannot be changed

Current Behavior

In 3.0.0 beta the flow title / name / label cannot be changed any more. The appropriate field does not exist.

Also the comment or documentation tab is not available any more.

Expected Behavior

Flow label can be changed.

Steps To Reproduce

grafik

Example flow

paste your flow here

Environment

Node-RED version: 3.0 beta
Node.js version: 16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

RealFlachmann issue comment node-red/node-red

RealFlachmann

RealFlachmann NONE

createdAt 10 hours ago

wontfix

Flow Title cannot be changed

Current Behavior

In 3.0.0 beta the flow title / name / label cannot be changed any more. The appropriate field does not exist.

Also the comment or documentation tab is not available any more.

Expected Behavior

Flow label can be changed.

Steps To Reproduce

grafik

Example flow

paste your flow here

Environment

Node-RED version: 3.0 beta
Node.js version: 16.15
npm version: 8.10
Platform/OS: Windows
Browser: FF

RealFlachmann

comment in 10 hours ago

Ok, didn't found this upfront! Cheers!