Follow Pull request proposal - temporary node status : I stumbled upon this interesting topic by chance. I would have a suggestion with the following format: type NodeStatusFill = "red" | "green" | "yellow" | "blue" | "grey"; type NodeStatusShape = "ring" | "dot"; interface NodeStatus { fill?:…

@GogoVega I don't like the ephemeral flag because I will have to simulate the code to determine the previous status, when: I haven't touched the code for a while new maintainers that didn't write the code the status transitions are dynamic Therefore, my proposal is: A callback can be provided w…

Very briefly put: an ephemeral status is purely visual, it does not trigger the status node and is only sent to connected editors (no retain mechanism). Of course ephemeral = limited in time. The point to clarify is regarding the static status (the current one); if duration is defined two behaviors…

[image] AllanOricil: A callback can be provided when duration is set. node.status({ text: 'foo', duration: 3000, ()=> 'bar'}) That's the idea behind the list, but as Dave pointed out, it complicates things, and in practice, statuses aren't predefined. Now, if you have other ideas/comments, …

[image] GogoVega: statuses aren't predefined. Could you write a code example to let me better understand this statement, please?

If I take my nodes as an example: When the database connects, the node's status is connected. This status is static. Now a message arrives and a query is made. I'd like to create a visual status that indicates querying.... When the query is finished, I'd like to create a visual status query done l…

[image] GogoVega: rigger the status node is maybe the best practice node.status({ text: "error", duration: 5000 }) I don't think that would be right to be honest. I doubt I would want a status node to be triggered just because I am reverting back to a previous status, only if I send a new sta…

Honestly I don't know if the error status should trigger the status node. It's also the role of catch node (because node.error is called).

You already said that you thought ephemeral statuses should not trigger the status node and I think that is correct. In any case, an error should trigger an error, you should not rely on status for that I don't think.

I understood it now. I can see ephemeral and duration as independent variables. ephemeral when true it does not trigger status nodes/effects and and it also does not change node._previousStatus, which is managed by the core. duration when set the node goes back to its previous status using node._p…

My side: async query(){ this.status({ text: "querying...", ephemeral: true }) // let's say the default duration is 5s - the process took <1s await this.db.model.fetchMany(...) this.status({ text: "query done", ephemeral: true, duration: 200 }) } The idea behind the runtime is t…

Node-RED

Node-RED Forum

Support for node status list and duration

Core Development Feature Requests

GogoVega 7 September 2025 21:15 51

Both possibilities are good. It's up to our gurus to decide

It will depend on the use that is most likely to be used.

Topic		Replies	Views
Pull request proposal - temporary node status Feature Requests	40	1769	19 August 2020
Make the status node have an input Feature Requests	26	755	18 March 2023
Feature request: message delivery pending Feature Requests	33	1031	12 April 2023
[PR Discussion]Debug default node label text Core Development	44	2146	5 September 2018
Status Node - how does it work? General	11	1042	1 August 2020

Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Support for node status list and duration

Related topics