====== 10.3 Node Startup Behavior ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:10-node-implementation-pattern:start | Return to Node Implementation Pattern ]] A [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] should perform startup in a predictable sequence. Startup should establish the runtime context, validate the [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]], initialize [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] participation, prepare publishers and subscribers, and publish the first observable [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status. A representative startup sequence is: - Load Node Configuration. - Validate required Configuration values. - Initialize logging. - Determine Node Identity and Node Role. - Publish or prepare to publish ''Starting'' status. - Initialize DDS participant Configuration. - Create required publishers and subscribers. - Register or initialize topic participation. - Validate required runtime dependencies. - Publish ''Running'' status when startup succeeds. - Publish ''Failed'' status and exit when startup cannot complete. The Node should fail clearly when startup requirements are missing or invalid. Startup should not continue silently when Configuration, DDS setup, generated types, topic names, credentials, runtime paths, or required dependencies fail validation. Startup logs should record the Node name, Node Role, Configuration source, DDS toolset or runtime context where available, topic participation, and final startup result. Logs should not expose secrets or sensitive local Configuration. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.