# Static Node Reference Resolution and Initialization Ordering in Node-RED
**URL:** https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192
**Category:** Feature Requests
**Created:** [28 September 2025 01:38 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192 "2025-09-28T01:38:15Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 01:38 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/1 "2025-09-28T01:38:15Z")
**OBS: This is not talking about the flow/wiring order resolution, but the static references resolutions (nodes used by other nodes in their config. E.g. node A is set with node B using a typed input)**
Nodes that include static references(id) to other nodes in their configuration must access the referenced instance during initialization. If the referenced node hasn’t been initialized yet, calling RED.nodes.get(config.referenceId) will be null
When the reference is a config node I dont have problems because config nodes are initialized before. However, if a non config node references another non config node, because the node instances were not sorted and instantiated based on their static dependencies, the initialization of the referenced instance can happen after the node that references it.
I have a node that reference different non config nodes. If the node I used as reference was not instantiated while my node instance is being created, then my node won't be initialized correctly.
**Examples:**
**1 -** All the following nodes were referenced as a "config" of another node. It doesn't matter if they are config nodes or not.
A depends on B
B depends on C
C depends on D
C depends on E
There are no cycles. Therefore, the order of instantiation/function call is: E -\> D -\> C -\> B -\> A
**2 -** When cycles are found, a runtime and editor error are thrown with the following message: `Remove the following cycles and try again: [A_id, B_id, C_id] `
A depends on B
B depends on C
C depends on A
The main benefit would be **early validation + deterministic initialization**. Without it, developers are currently using the following workarounds:
- Delay setup until the first message (hacky, error-prone)
- Require ugly retry logic (checking `RED.nodes.get()` until the reference appears)
- Implementing what should be a core pre-setup functionality by themselves
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 06:56 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/2 "2025-09-28T06:56:21Z")
Note that the editor sorts nodes during a deployment to first instantiate all config nodes and then regular nodes. If your problem is related to a regular node (the referenced one), we can still add a filter to solve it.
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [28 September 2025 09:01 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/3 "2025-09-28T09:01:24Z")
> [@AllanOricil](#):
>
> If the node I used as reference was not instantiated while my node instance is being created, then my node won't be initialized correctly.
As above, Config Nodes are "Started" first - that's by design.
But if your config Nodes do async work that is not yet completed, before it has had a chance to service the subscriber Nodes (lets say the config Nodes are attempting to connect to a 3rd party network service), then your subscribers may fail - as the config Node is not yet ready to provide service (i.e its doing something async, before its truly ready)
I tend to employ the register, de-register approach for this.
```auto
/* Config Node */
module.exports = function (RED) {
const init = function (config) {
const self = this;
self.subscribers = {};
self.registerSubscriber = (NodeID, Callback) => {
self.subscribers[NodeID] = { Callback };
if (self.ready) {
Callback({
some_state_object
});
}
};
self.deRegisterSubscriber = (NodeID) => {
delete self.subscribers[NodeID];
};
/* Or some event in your logic */
self.onReady(() => {
Object.values(self.subscribers).forEach((S) => {
S.Callback({
some_state_object
});
});
});
};
};
```
```auto
/* Subscriber */
module.exports = function(RED) {
const init = function(config) {
...
const self = this;
self.config = RED.nodes.getNode(self.config.runtimeId);
self.config.registerSubscriber(self.id, (object) => {
if(object.someReadyEvent){
...
}
});
self.on('close', (_, done) => {
self.config.deRegisterSubscriber(self.id);
done();
});
}
}
```
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 09:08 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/4 "2025-09-28T09:08:14Z")
Thank you marcus. I liked what you did there.
How do you do when a non config node reference another non config node? With typed input fields we can select non config nodes when opening a node's form
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [28 September 2025 09:16 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/5 "2025-09-28T09:16:25Z")
I can't say I have ever had the situation.
But in the HTML, you can check if the Node type exists in the flow perhaps?
and warn the user if not found - prompting them to first instantiate the dependancy Node?
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 09:19 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/6 "2025-09-28T09:19:19Z")
> [@marcus-j-davies](#):
>
> But in the HTML, you can check if the Node type exists in the flow perhaps?
It has to be on the server side, similarly as you did above. It is a runtime issue
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 09:21 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/7 "2025-09-28T09:21:49Z")
> [@GogoVega](#):
>
> first instantiate all config nodes
Thank you gogovega. But my use case is non config nodes referencing non config nodes
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 09:24 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/8 "2025-09-28T09:24:33Z")
> [@AllanOricil](#):
>
> With typed input fields we can select non config nodes when opening a node's form
Not tested. But the internal `type` property of node definition works with regular nodes.
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [28 September 2025 09:26 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/9 "2025-09-28T09:26:15Z")
I could have this wrong...
But maybe something like this in your Logic?
```auto
RED.nodes.eachNode(function(n) {
if (n.type === 'targetNodeType') {
found = true;
}
});
if (found) {
// Cooking with gas
} else {
this.error('Please deploy xxxx node')
}
```
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 10:25 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/10 "2025-09-28T10:25:40Z")
Not talking about node type registration order, but node instantiation order
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [28 September 2025 10:36 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/11 "2025-09-28T10:36:51Z")
Ok - I think this has come up a few times....
Whilst I could be wrong - the _current_ execution order can be guessed via the right panel.
what could work, is having the ability to drag priority
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 11:06 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/12 "2025-09-28T11:06:36Z")
So... the fix would be a filter on regular nodes like config nodes does.
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 11:15 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/13 "2025-09-28T11:15:33Z")
> [@GogoVega](#):
>
> So... the fix would be a filter on regular nodes like config nodes does.
Could you describe what you thought more clearly?
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 11:17 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/14 "2025-09-28T11:17:52Z")
> [@AllanOricil](#):
>
> However, if a non config node references another non config node, because the node instances were not sorted and instantiated based on their static dependencies, the initialization of the referenced instance can happen after the node that references it.
Filter regular nodes to first instantiate _linked_ nodes.
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 11:21 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/15 "2025-09-28T11:21:53Z")
Im not sure how you are thinking about using this filter, but I don't think it would work when a referenced node can have another reference. In this scenario which node is instantiated first (A, B or C)? This type of problem is solved using topological sorting
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 11:24 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/16 "2025-09-28T11:24:41Z")
>
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 11:37 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/17 "2025-09-28T11:37:09Z")
This for the editor
`packages/node_modules/%40node-red/editor-client/src/js/nodes.js`
If the server has something similar to that, it won't work because I need the instance reference during the constructor of the node that uses it.
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 11:46 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/18 "2025-09-28T11:46:38Z")
I know topological sorting can't be used in the flow because there can exist cycles (it is not a DAG). But there can exist a smaller graph for static references (ids), that would be used to compute the topological order of non config nodes used in the configuration of other non config nodes. Couldn't it?
---
### Author:  [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [28 September 2025 11:48 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/19 "2025-09-28T11:48:45Z")
You mean for the runtime. Ok it's very simple: no way.
The only topology there is, is to start the global flow first (which contains global config nodes). From memory it is designated this way because the nodes do not have their own initialization. I mean that the runtime does not know if a node is fully initialized or not. Moreover, this would complicate and slow the startup of flows.
---
### Author:  [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)
#### Post date: [28 September 2025 12:02 UTC](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192/20 "2025-09-28T12:02:39Z")
> [@GogoVega](#):
>
> You mean for the runtime. Ok it's very simple: no way.
This isn't an answer. I would like to know a "why".
_ **Is it technically impossible? If yes, why? Or is it because we don't know or don't want to do it?** _
**obs: just to be assertive. Im not trying to frame or expose anybody. Don't get me wrong or feel threatened, please. I really just want to see if I can help to improve node-red.**
I believe this would be possible if instantiation and wiring were handled in separate phases. The idea is to build a small DAG to determine the correct instantiation order for nodes that are referenced in other nodes’ configurations. These references could point to either config nodes or non-config nodes. With this approach, when my node is constructed, its dependency instances would already be available in the constructor. This would make it possible to properly compose nodes.
And again, I'm not talking about changing the flow/wiring order
[Next page](https://discourse.nodered.org/t/static-node-reference-resolution-and-initialization-ordering-in-node-red/99192.md?page=2)