"Otherwise" evaluated to early in switch node

[overlinden]

Current Behavior

Due to flow layout reasons I changed the order of the cases in the switch node to

1. otherwise
2. my condition

I recognized that the message is forwarded to both outputs which causes unexpected behavior.

Expected Behavior

The order of the cases should be honored. Nevertheless I expect the "otherwise" to be evaluated at last wherever it is located in the conditions of the switch node.

Steps To Reproduce

• Create a inject node that outputs 10.
• Add a switch node with two cases
• First case "otherwise"
• Second case "==10"
• Connect debug nodes to the outputs

You will see that the message "10" is printed for both outputs.

Example flow

[
    {
        "id": "1b4565177e64597f",
        "type": "tab",
        "label": "Spielwiese",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "397f959470a9d42d",
        "type": "inject",
        "z": "1b4565177e64597f",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "10",
        "payloadType": "num",
        "x": 330,
        "y": 180,
        "wires": [
            [
                "d0b3cc0257b30930"
            ]
        ]
    },
    {
        "id": "d0b3cc0257b30930",
        "type": "switch",
        "z": "1b4565177e64597f",
        "name": "",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "else"
            },
            {
                "t": "eq",
                "v": "10",
                "vt": "num"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 530,
        "y": 180,
        "wires": [
            [
                "2bcffee607a97e7f"
            ],
            [
                "a364ae22bedf1205"
            ]
        ]
    },
    {
        "id": "a364ae22bedf1205",
        "type": "debug",
        "z": "1b4565177e64597f",
        "name": "debug 2",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 700,
        "y": 140,
        "wires": []
    },
    {
        "id": "2bcffee607a97e7f",
        "type": "debug",
        "z": "1b4565177e64597f",
        "name": "debug 3",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 700,
        "y": 220,
        "wires": []
    }
]

Environment

I am running the official Node-Red docker image on a linux host.

[hardillb]

Order matters and otherwise is expected to be last

[overlinden]

Yes, this is the actual behavior and from a programmers perspective that is reasonable. After I found out that makes sense to me as well but this seems to be unintuitive for some non technical users.

[dceejay]

I don't think there is anything to fix here is there ?
OK to Close ?

[My-Random-Thoughts]

While this may be obvious to technical people, is it worth adding a note to the switch node to say rules are processed in order from top to bottom?

[GogoVega]

This might be a bit of a "stupid" message. This behavior is directly related to programming and not to Node-RED, I rather suggest a light learning in the tour(1) way (a few basic rules to get started). This idea can be very interesting for real novices. The question being is it profitable to code it?

[1] the window with the new features of the current version.

[mobamoba]

I'd just add one thing: the switch node defaults to "checking all rules" which, to my non-programming mind, certainly seems to say the order of the rules makes no difference. I note this because I, too, have sometimes put "otherwise" first only to discover my flow didn't work properly since I assumed the node was going to check all rules since... that's what it said it would do.

If "otherwise" is always last from a programmer's POV, perhaps it could automatically be placed last when selected by the user or at least clarify what "checking all rules" means since that implies order is irrelevant. Or name it "otherwise (must come last)" or somesuch so the end user knows.