With MsgFlo coordinator we have two ways to have processes appear in the graph:
- Started by MsgFlo coordinator itself
--ignored and assumed to be running somewhere and sending its own discovery messages
At start-up MsgFlo waits until each participant has been discovered and its connections set up correctly. Like with #94 if one participant doesn't send a discovery message in this behavior, MsgFlo coordinator fails with an error:
May 12 01:42:30 c-flo node[6216]: Error: Waiting for participant siri timed out
May 12 01:42:30 c-flo node[6216]: at Timeout._onTimeout (/opt/c-flo/node_modules/msgflo/src/coordinator.coffee:74:21)
May 12 01:42:30 c-flo node[6216]: at ontimeout (timers.js:380:14)
Instead, MsgFlo should be aware of what nodes/edges in the graph are "real", and what are "pending", and allow itself to start promptly, and then bind queues as participants appear (#127).
This is especially critical for setups like c-flo where many participants do get shut down at night.
Initially reported at c-base/mqttwebview#2
With MsgFlo coordinator we have two ways to have processes appear in the graph:
--ignored and assumed to be running somewhere and sending its own discovery messagesAt start-up MsgFlo waits until each participant has been discovered and its connections set up correctly. Like with #94 if one participant doesn't send a discovery message in this behavior, MsgFlo coordinator fails with an error:
Instead, MsgFlo should be aware of what nodes/edges in the graph are "real", and what are "pending", and allow itself to start promptly, and then bind queues as participants appear (#127).
This is especially critical for setups like c-flo where many participants do get shut down at night.
Initially reported at c-base/mqttwebview#2