🎉 Node-RED 5 now available

[jbudd]

I keep expecting to find a little X button on the titlebar of each side panel.

I'm looking at the panel thinking "I don't want to see that just now", then to close it I have to switch attention to the buttons at bottom right and work out which button is for which panel.

[gregorius]

@jbudd

I keep expecting to find a little X

That and the overlap on the right side with searched-for nodes being hidden under that sidebar so that I end up looking all over and then remove the side bar to finally find the node that was found.

[cymplecy]

I've not noticed this - I have info above debug - if I move info to left side - debug stays where it is at bottom right
Before dragging

After dragging info to left

[gregorius]

@gregorius

That and the overlap on the right side with searched-for nodes being hidden under that sidebar

For those facing this too, I've just testing this bit of JS

RED.events.on("search:open", () => {
    $($('.red-ui-sidebar-right').find('.red-ui-sidebar-section-bottom')).fadeOut(500)
    $($('.red-ui-sidebar-right').find('.red-ui-sidebar-section-top')).fadeOut(500)
})

RED.events.on("search:close", () => {
    $($('.red-ui-sidebar-right').find('.red-ui-sidebar-section-bottom')).fadeIn(500)
    $($('.red-ui-sidebar-right').find('.red-ui-sidebar-section-top')).fadeIn(500)
})

which hides the sidebar when the search dialog is opened and unhides the sidebar when the search dialog closes again:

[bakman2]

When using a http request node with a binary buffer i noticed that the status remains on 'requesting' (not a browser issue? both chrome/safari show it even after quitting the browser and reopening node-red)

[gerrybartley]

I've seen that issue too but I'm using Node-Red 4.1.2 in my production environment

[DWoodlock]

I also experience this “requesting” status display in 4.1.1

Have confirmed the node is posting as intended, just the stays display seems to hang up.

[dceejay]

Hi @bakman2 - do you have a simple example I can test with ? Thanks

[bakman2]

The plot thickens, this is weird.

The http req node remained in that 'requesting' state - it was fed into a function node that uses an external npm lib - disconnected the function node, deploy, requesting state gone, reconnected it and 'requesting' now behaves normally.

ie. i cannot reproduce it. Does the http request node 'care' about the result of the next node ?

[TotallyInformation]

@bakman2

Does the http request node 'care' about the result of the next node ?

I'm sure it would be a bug if it did since nodes aren't really supposed to be dependent on what happens downstream.

I suspect that you hit a timing issue where the request timed out before the response was recieved?

[dceejay]

looking at code there do seem to be some "holes" where status may not get cleared. Will take a deeper look later.

[gregorius]

@dceejay

"holes" where status may not get cleared.

I think I had this because Node-RED actually crashed and never sent the clear status call.

EDIT:

Ok, turns out it was a probably an endless loop that causes non-responsiveness in NR. So NR didn't really crash but just staled. I can reproduce this using this bit of code in the node:

module.exports = function(RED) {
  function CorecrasherFunctionality(config) {
    RED.nodes.createNode(this,config);

    var node = this;
    var cfg = config;

    node.on('close', function() {
      node.status({});
    });

    /* msg handler, in this case pass the message on unchanged */
    node.on("input", function(msg, send, done) {
        node.status({ fill: "green", shape: "ring", text: "Requesting" });
        setTimeout( () => {
          node.status({});
        },3000)

        // this enters an endless loop that eventually crashes NR
        setTimeout( () => {
          while (true) {
            setTimeout(() => { }, 0)
          }
        },1000)
    });
  }

  RED.nodes.registerType("crasher", CorecrasherFunctionality);

}

this will eventually cause this:

node-red-empty500-1  | <--- Last few GCs --->
node-red-empty500-1  |
node-red-empty500-1  | [7:0xffffa0950000]    32633 ms: Scavenge (interleaved) 4047.6 (4065.9) -> 4047.6 (4112.9) MB, pooled: 0 MB, 15.98 / 0.00 ms  (average mu = 0.164, current mu = 0.148) allocation failure;
node-red-empty500-1  | [7:0xffffa0950000]    34420 ms: Mark-Compact (reduce) 4048.0 (4112.9) -> 4048.0 (4051.2) MB, pooled: 0 MB, 1686.27 / 0.00 ms  (+ 20.1 ms in 6 steps since start of marking, biggest step 5.0 ms, walltime since start of marking 1710 ms) (average mu = 0.118,
node-red-empty500-1  | FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
node-red-empty500-1  | ----- Native stack trace -----
node-red-empty500-1  |

Which that leaves my flow like this:

Thanks to exploring this, I actually fixed my code by removing the endless loop